Some of us are apparently built to be fixers, solvers, and supporters. We are the elves at night that are not seen, but problems that would have happened without us now don't happen. And a problem that doesn't happen is a problem that's not noticed.
However, that drive to make things better eventually gets bogged down by the apparent lack of care or concern by many other people which leads to more new problems that often shouldn't exist. At some point, you step back and say, "Perhaps if I stop making things better, collapse will come sooner and then people will wake up and decide to pay more attention to their actions and outcomes."
Technical debt is sometimes an intentional trade-off between short term and long term goals. There are times when we would agree that we can cut some corners or not plan for certain expected futures because our time is precious and limited.
When such decisions are weighed before taking action, technical debt is acceptable. But when people are either too inexperienced or simply don't care, the tech debt is just wrong.
What's even more demotivating is watching inferior tools become the most successful, especially as those tools seem to attract the kind of developers who don't see or don't care about software and system quality. These are the people who, when you show them an alternative approach (which has less risk or long term cost - and even without much additional upfront cost), they inevitably say, "Why would you do that? This works fine." And so you end up with 200 line functions, horribly tight coupling everywhere, copy/pasted blocks of code everywhere, etc.
Another demotivator is when key decision makers are too comfortable with "how it has always been done" and are unwilling to grow to the new challenges and company size. You could hustle and deliver proof of concepts which show how company wide shared architectures would reduce effort across most teams (silos) while increasing reliability of systems... and ease of employee migration from one team to another. But after doing things like this and making traction perhaps 1 in 10 times, you eventually decide it's not worth trying. CBF. Meanwhile, the same tech leader is constantly harping about our need to hire more engineers. So clearly, the answer is not work smarter, but throw more people at it and build more variations of tech debt. (When a new engineer is faced with maintaining a debt-ridden legacy project, they don't stick around long.)
I'm sure every profession has some version of all of this, but our seems especially nasty in this regard. I used to balk at the idea of professional certifications before one could be a software engineer, but now I think it would be worth it. Everyone should have to understand and demonstrate more than just passing Leetcode challenges to work in this field.