That's what I call the 'happy path fallacy'. If code performs along the happy path, then great, move fast, break things and release. Never mind that outside the happy path there are tons of issues, bugs, things never even looked at until they suddenly are found to be the root cause of a major breach. Those parts do not get the attention they need because there is no direct economic incentive to do so.
Software is not at all done when it 'works'. It's only done when it works well for all input and there are no unknown paths of execution that lead to unexpected results. It's pretty rare for a codebase with more than a few 100 lines to be completely known to such a level that there isn't a way to cause it to do something the author did not intend to be there. Complexity is a very bad enemy in that respect and code tends to get extremely complex and hard to reason about if you don't have iron discipline during the design process.
If you write code fast because you have a life at home to get to, and I write code fast because my employer needs it right now, and someone else writes code fast because they have a large ego to maintain, what really is the difference? If the simplest thing to do is also reasonably secure then the hope is a 30 minute deadline will not lead to an accidental security flaw.
Yet if anyone added up the manhours it took to fix the same production issues that repeatedly popped up, it would've clearly been less expensive to fix the recurring bugs.
If you've got a deadline in thirty minutes, you're probably not going to try and do everything the best possible way. Same deal if you've got a family or friends to get back to, an event to go or anything else that requires you to get things done quickly.
You're rewarded more for getting things done quickly than you are getting them done properly or securely. When your client wants their site or program done as quickly as possible for a low cost, or your startup needs to 'move fast and break things'... security will usually suffer in the process.