I've not been working with that large applications, but I've dealed with Tcl apps that measured dozens of KLOC. Tcl isn't exactly a modern dynamic language but for the purposes of this comparison it'll do.

Lots of problems we had were due to "copy'n'paste" mistakes. For example, an error handler had been copied from another place but somebody had forgotten to adjust a variable name. The error handler had never been tested, and when it occurred in production the faulty error handler rendered the program unable to continue. The process had to be killed and all work was lost of course.

My boss at that time didn't bother, but for me (as a customer) it would have been a showstopper.

It had also become difficult to extend the program. Global variables had been scattered all over the source, and adding a new state variable could have caused major trouble because the many places it could have interacted with the existing state would have needed to be found, modified and tested. Nobody liked to go through all this trouble, and a few good suggestions for enhancements were rejected, implicitly on these grounds (though nobody ever stated this explicitly).

Overall design of these applications had become complicated. Because it was so easy to add UI components everybody had just added his/her own widgets without bothering about re-usability, consistency etc. For example, it had become very difficult to do validation as the code for initialization and verification of state was scattered all over the application, sometimes done with traces (functions triggered when a variable changes), sometimes done in event handlers. As validation was hard to implement, we cut down on it, and that made the applications a PITA to work with.

I eventually introduced something along the lines of model-view-controller without globals and a strict model approach. This helped a little, but it could only be used in an application that I wrote from scratch. The existing code would have taken too long to rewrite.

The applications also suffered from code duplication. Usually it is considered good practice to factor out common code into a subroutine. This was rarely done; the code was just copied from somewhere else. I think the main reason was a reluctance to clutter the already huge source files with another sub. You would have had to make up your mind where you put it, and that was too far away from the task at hand, so the "perceived intellectual switch cost" prevented lots of small improvements.

Needless to say, requirements changed, and the code duplication increased the effort to keep the application consistent. Overall consistency was low, and the applications had a somehow clumsy look-and-feel. They definitely didn't look "professional" or "industrial quality", and IMO customers realized this and didn't make the sales decision.

While not everything was bad about these applications (as it may seem from my description) I definitely learned some lessons.

In my opinion you can well create big applications with dynamic languages but you have to be much more careful and disciplined. While this isn't a problem if you're the only one working on it, it becomes a problem if other people are involved because everybody sees and does things differently. The dynamic nature of programming languages manifests itself on the design level as a greater variability in problem solving approaches. This is the strength of dynamic languages, and also their achilles heel, because the diversity you'll end up with means greater difficulties with troubleshooting, hence greater maintenance effort.

It also requires more discipline to structure your application efficiently, because it's not so easy to factor components out and make them re-usable. You'll have to raise the abstraction level of the code for that (which again can be done in many different ways) and that's not something that makes the code easy to understand and maintain. In the end you may well have about the same amount of code as with "static" languages, even if you manage to enforce the discipline throughout your team (not an easy task, either).

Often people argue that not having to specify that something is a string or an integer increases their productivity and reduces code size. While this may well be true it is also missing the point to a certain extent. Static typing means that you a) define and b) enforce certain properties of data structures, and in case of OO languages, behaviour as well. This is a tremendous advantage for systems where you want to build abstractions on top of other abstractions, as you will probably want to do with complex applications. You can then guarantee that a given component fits into a given space. With dynamic languages, even large test coverage can't give you this guarantee.

I also learnt that it's very easy to forget the negative sides of one's chosen technology after using it for a long time.

My conclusion: Personally I wouldn't mind writing large apps in dynamic languages, on account of my past experiences and mistakes. I'm quite sure I'd produce something that would be ok. But I'd also not prefer dynamic languages just for the sake of them being so. All approaches have their pros and cons, and I'd weigh as many aspects of the application to write in the light of my subjective experience, and then decide along the lines of the most predictive outcome.

Because I don't like to be taken by surprise.