In the recent Secure coding (and Application Security) must be invisible to developers post Joshbw posted this great comment on the reasons why we end up with 'insecure by default Frameworks'
In a way Microsoft's (and Spring's) decision to chose the insecure default (see Spring MVC Autobinding Vulnerability) is probably the correct business decision.
Choosing the secure alternative, would introduce a hit to development (Joshbw thinks this would be marginal, but I'm not so sure), which these Framework developers felt could create a bad user experience (their users are the developers) and could potentially drive away users into other frameworks that had such 'by default' AutoBinding features.
This is why I say that We need Security-focused SAST/Static-Analysis rules so that we can deal with the cases where AutoBinding creates vulnerabilities.
In fact, a good example of security adding value to developers would be if those SAST rules (via an security engine) would actually automatically introduce those 'Declarative Bindings' without requiring a developer's intervention (this could happen behind the scenes , 'invisible' to a developer, unless that was creating business impact (i.e. side-effect).
To see an example of what this could look like, take a look at The future of secure code? Fixing/Encoding .NET code in real time (in this case Response.Write)
On the commercial SAST front, as far as I know, only Armorize ventures into this 'code fixing territory'