Those projects that pay more attention to security than this baseline generally want to simply apply whatever the off-the-shelf recognized best practice is, in order to minimize their investment in besides-the-point-for-now-anyway security. The last thing they want to do is adopt an architecture that requires their programmers to spend their precious attention learning something unconventional that does not contribute to their project's early survival.
The exception is those projects, like Sandstorm, whose point is inherently to deliver a novel form or degree of security. But if their products are only useful to customers that need to learn something new, then those customers are rare for similar reasons.
These problems are hard to overcome. Recently I was advising a startup company whose point was well outside security. I was advising them uncompensated because I desperately want them to succeed. The reason they asked me for advice is they are aware of my security work and wanted to build a capability system. I painfully found myself advising them not to because it would be a costly distraction from issues more likely to kill them sooner. If I did not care so much to see them succeed, I wonder whether I would have been as successful at overriding my own biases to give them good advice.