I think it’s fairly simple - security often slows down development and competes with features. Product managers get their way, and features can trump bug fixes for far too long.
Developers don't like security features that make development slower either.
I made the mistake of adding Content Security Policy to an app that was still in the prototype stage and it caused endless headaches whenever I needed to add new dependencies.
Your app shouldn't be outright insecure, but defense in depth (e.g., security features that are only useful contingent on the presence of another security vulnerability) can be safely deprioritized until your app gets complex enough to need it.
I'd accept "until your app looks like it might leave proof-of-concept classification".
And always be mindful of how quickly PoC code can magically end up needing to be production ready overnight or worse being in production before it is... Retrofitting security can be a nightmare, one that can be so easily avoided.
I once nearly left a company because of being ordered to ignore a massive security problem in a legacy application that was actively used by many people to instead concentrate on tweaking bells & whistles on the shiny new thing that hadn't left prototype yet. That would have been fine if other resource was assigned to the security issues, but it wasn't. They did eventually see sence, but I didn't exactly make myself popular with the powers that be at the time.