Grammar ends up becoming a problem on a few fronts. I highly recommend
Principles of Compiler Design [1].
One safe rule of thumb is, as grammar and rules expand, the performance and simplicity of the compiler begin to deteriorate, particularly if features aren't added carefully.
The second is in practice, the additional grammar gives you far more ways to tackle the same problem. The is the conundrum that metaprogramming gives in languages like Ruby. Teams begin the phase of coding to the domain before letting other things fall into place.
Thinking ahead is good, but I think the issue is Scala's grammatical flexibility makes it too tempting to dig ourselves into a DSL before we're really ready. This is why we'd get so grumpy when PM's came to us asking for new features that'd require a refactor. We bought in to our own idioms, if we programmed things without the DSL, we'd be more nimble.
And we're not dumbasses. We're experienced programmers with experience programming in that domain before, but the target always ends up moving for reason's outside of engineering's control. From experience we know, DSL has no place until you're very secure in what the needs of the business is.
That said, no codebase is future proof to the rest of the team needing last minute changes - but I feel scala forces you into design decisions too early, and we thought that was an advantage.
Actually, I liked scala for not having Java's boilerplate. Then I began to miss those old things java forced you into.
It was painful, because the ego investment the team had in scala was huge. A lot was on the line. Crow had to be eaten.
[1] http://en.wikipedia.org/wiki/Principles_of_Compiler_Design