What efficient methodology is there to write a large codebase using a scripting language that can't be used with a compiled language exactly? The "you need better developers" fallacy is exactly that, a fallacy - it doesn't matter how good your developers are, all developers introduce bugs, certainly the number decreases as you increase the skill of developers but there is not a developer on this earth that does not introduce bugs.
So there lies the problem with scripting languages, because many scripting languages don't have any kind of toolchain that prevents bugs from creeping all the way through until runtime, you have entire classes of bugs that a compiler would catch creeping through to your executing application at runtime, as the codebase grows scripted applications therefore by and large almost entirely all become much more time consuming to debug, as bugs only appear in fringe cases and it is not immediately obvious how to reproduce them. Often you find yourself having to implement tremendous logging infrastructure and so on and so forth to have confidence that your application is solid and the net result is that it's just way more efficient to develop large projects with a compiled technology. Also, whilst it's not a fault of scripting languages per-se, you tend to find that compiled languages have far superior toolchains for developing large projects in the first place anyway.
I don't say this as someone spouting opinion and theory, I say this as someone who has had experience as both a lead developer and technical architect in implementing large projects in both compiled (native and managed) and translated languages (which is usually what people mean when they say scripting, though it's getting muddier with more use of just in time compilation etc.), and even some projects mixing it all together.
For anything large the amount of time spent debugging scripted applications just gets too large for it to be worth it, at that point you might as well have used compiled because any early benefits of getting up and running quickly have long been lost.
Which isn't to say I'm of the opinion that scripting languages are always useless, not at all, I think they're fine for small non-mission critical tasks such as task automation, and for prototyping, but I think the larger a project gets, the less worthwhile scripting languages become - that's not to say you can't use them, as I say, I have myself been involved in such projects, but the project is always much more costly. This is evident at companies like Facebook with their use of PHP - last time they released server specs they had equivalent of 8gb of RAM per user of Facebook which is insane, even if a lot of that is being put into big data type processing and analytics, and the amount they've spent trying to turn PHP into something compiled similarly paints the same picture. So yeah, sure, Facebook is there, and it works, most of the time, but it's also costing them way more to run than it should if it was a properly planned project using something like Java, C++, or even C# from the outset. The flip side is, someone like Zuckerberg who was just hacking a de-facto prototype together may also never have been bothered, (or potentially even competent enough?) to do so with a compiled language and a more professional architecture, so it's a double edged sword in that respect, and I can see why many startups like to just get something developed no matter how crappy using the quick to launch (but poor to maintain) benefits of scripting languages.
The Google approach (well, it's probably unfair to call it the Google approach, other big players were doing it long before them) of writing the mission critical or speed critical stuff in Java or C++ respectively and using something like small manageable chunks of a scripting language like Python to string it together is not a bad option.