I think that having "The Google-way" is certainly valuable to Google (and engineers). Because there are only a few ways to do things you can build something and then hand it off to another time (SRE) for day-to-day operations. It also makes security and machine management much easier to deal.
I'm not saying you're wrong, just pointing out the flip-side.
Maybe Google should have a separate network with separate virtualized machines and no "Google stuff" for new medium-sized projects. Test whether they get traction there and then port them into "the Google-way" later.
Or maybe "the Google-way" just needs to be fixed up to make it easier. For example you could use AppEngine.
Agreed 100% on making dual infrastructure. Google Search and other high-reliability products need to stay on time-tested infrastructure.
Making a "wild-west" of infrastructure (a-la an in-house EC2) would really be the right way to go. And, as you said, put small & medium sized stuff there, and make porting over a moderate but not impossible task.
With respect to AppEngine, it's often stated as some kind of panacea solution for scalability for small applications. But, as a web application developer, I see AppEngine as "Googleisms on the outside". And by this, I mean that AppEngine is also a walled garden. Can you access a MongoDB instance from AppEngine? What about memcached for caching? Solr for document indexing and search? These are all things that are easy to do in a dedicated machine environment and greatly benefit small projects, but are impossible via anything Google builds.
I'm not saying you're wrong, just pointing out the flip-side.
Maybe Google should have a separate network with separate virtualized machines and no "Google stuff" for new medium-sized projects. Test whether they get traction there and then port them into "the Google-way" later.
Or maybe "the Google-way" just needs to be fixed up to make it easier. For example you could use AppEngine.