It creates a sensible layered conceptual model in the heads of software developers that fits dynlangs on top of static langs which, in turn sit on top of bytecode. This is a good way to gently veer developers towards the power of dynlangs.
I remember in the Eighties finding myself gently weened off direct 8086 assembler and into C because I could still code bits in assembly if I wanted to and "glue" them together with an over-arching C-based application. This preserved my ability to use assembler if I needed it but gave me significant extra flexibility and a productivity boost to boot.
Same model today - just one level further up the stack of layers. Nowadays, you can (should!) be coding up whatever modules require C#/Java/C++ static typing directly in that language and then glueing the modules together in a dynlang framework. That gives you the ability to directly code in C#/Java/C++ when you need it but gives you significant extra flexibility and a productivity boost to boot.
If I were operating in full dynlang propaganda mode I should probably stop now but I'm not so I won't. There is a further developmental stage to this model. It goes like this...
- At first, I used to code up modules in assembly and link them together with my C modules in an overall, C-based application.
Over time, the number of times I would resort to diving into assembler got fewer and fewer. Eventually, I was coding end-to-end C applications. The drop in run-time speed was more than compensated for in terms of productivity.
 In my opinion :-)