I understand where you're coming from with all of those points, but I take a different view on most of them.
For example, I would argue that going a couple of weeks without delivering new features is far from a long time. If your features are so simple that they can all be added in that sort of time frame, and if failing to do so is enough for a competitor to cause serious damage to your business, then it seems unlikely that you had a strong business model/value proposition in the first place.
Likewise the idea of sitting on a known and unexplained data loss bug indefinitely is horrifying. Again, if you don't consider removing that kind of liability a priority, it seems like a matter of time before something disastrous happens. Depending on the nature of your work and the data involved, this might even amount to negligence and give legitimate grounds for affected customers or regulators to take legal action.
Finally, if you have management who expect everyone technical to be an expert on all technical tools and make perfect choices, then they are both ignorant of how techincal fields work and extremely poor at managing risk on a project. Once again, with that kind of person at the helm, you are already doomed.
Personally I favour tried-and-tested over new-and-shiny for most projects. My experience has been that many new and trendy tools have a good sales pitch but don't stand the test of time. After using them for real for a while, developers often start to understand why things were done the way they were done before and discover that this week's silver bullet comes with limitations or risks of its own.
In any case, whether you're using time-tested tools or expecting that newer really is better, building up technical debt to unmanageable levels will kill any software project. You learn as you go along, and at some stage your greater experience may suggest that a different approach would give much better results, and then you have a cost/benefit question of whether and when it's worth doing that work.