I agree that switching stacks is neither easy nor cheap, but building as you learn is absolutely possible.
I have scaled complex web systems to 25M monthly active users and switched stacks midway, yes it was incredibly painful.
However if we had started building out something custom right from the get go, we would have never reached the 25 MAU.
From what I understood, Rick wants to build a system to host multiple stores and aggregate of products across all stores would reach millions.
If the real bottleneck is the MySQL, not PHP. For MySQL to stay performant, the data needs to be smaller than the RAM. As soon as you start hitting the disk you experience non linear performance loss.
Since each store has different tables, it is easy to split multiple stores across multiple machines. This helps keep data on each machine smaller than memory. There are several more performance hacks that can keep the system blazing fast.
Magento has a pretty decent caching system, and its very easy to move the caching system for internal catalogues and session variables. it's easy to move the cache storage to a Redis backend, which is an in memory database and much faster than disk based storage. Another speed hack is sticking a varnish server in front of the cluster which can add a a significant performance gain.
If an individual stores catalog does grow beyond 500K items then indexing, url rewrites, search will slow down. A lot of these can be addressed with the help of commercial import and export tools and solr.
I guess what I am trying to say is, there is a way to make imagento work in case Rick scales really fast. If I was in his shoes, I would not hold the launch hostage to a new platform, I would launch something on magento. Use my learnings to develop a custom platform in parallel.