The best languages for writing quick-and-dirty 15-minute scripts are never going to be the best languages for million-line, mission-critical applications, the best languages for embedded programming are not going to be the best languages for web programming, and the best languages for beginners are not going to be the best languages for more advanced programmers.
So perhaps programmers sometimes give up too quickly and could do better on all those fronts, but it's not some limitation of the real world that forces the tradeoff: it's the fact that different decisions regarding things like syntax or the type system do have a real impact on the suitability of the language for different purposes, and you can't be all things to all people there. Sometimes you want a very loose language that doesn't get in your way; sometimes you want a very strict language that ensures correctness; sometimes you want a language that lets you manipulate things close to the metal; sometimes you want a very simple language that's easy to learn because it doesn't have too many concepts; sometimes you want a very advanced language that gives you lots of different ways to solve problems.
No language can or should be all things to all people.
Of course . . . you can also use a flat rock to hammer in nails when framing a house, but a framing hammer might be a better idea. Doesn't mean it can't be done, though, especially if you're really good with rocks and already have them lying around, whereas you'd have to go to the hardware store just to buy the framing hammer.
My point was not "language X can't do project type Y," but rather that the things that put a language in the sweet spot for certain types of projects kind of inevitably pull it out of the sweet spot for other types of projects. I.e. it really is always about trade-offs. Sometimes the mere fact that you know how to use a given language is enough of a win to outweigh any potential benefits of switching to another language.
While I'm not a big fan of Tcl/Tk, I'm quite familiar with it and find I this statement confused or misleading in at least two ways:
First, GWL once told me the bulk of the code is actually rather mundane GUI form definitions (the sort of crap that is trivial to generate with high level interface tools). There's only a small amount of actual "logic" at that level that ever needs to be maintained (the real control isn't done in Tcl).
Second, even if there are 50,000 lines of Tcl (actually I think the actual number is closer to 300,000), it doesn't mean it's one big script. It's probably more fair to compare it to a unix system with hundreds or thousands of separate smaller write-once scripts.
Ironically I think the real fault here lies with GWL and other Tcl enthusiasts for quoting a true but misleading "number of lines" in the first place. The number of separate scripts and average script length would be more meaningful and representative of the system's real complexity.
The general purpose language has been very successful because there's sufficient commonality between the operations that a lot of programs enact (what is good for one is good for the other) but the DSL has been also, perhaps a lesser extent, because of the benefits of specific optimisations you mention.
So perhaps programmers sometimes give up too quickly and could do better on all those fronts, but it's not some limitation of the real world that forces the tradeoff: it's the fact that different decisions regarding things like syntax or the type system do have a real impact on the suitability of the language for different purposes, and you can't be all things to all people there. Sometimes you want a very loose language that doesn't get in your way; sometimes you want a very strict language that ensures correctness; sometimes you want a language that lets you manipulate things close to the metal; sometimes you want a very simple language that's easy to learn because it doesn't have too many concepts; sometimes you want a very advanced language that gives you lots of different ways to solve problems.
No language can or should be all things to all people.