Paper-Cut issues

When building products there are often issues that are never urgent, but get progressively harder to resolve for every day they aren't. Migrating a database table is an example. These problems can often cause death via 1000 paper-cuts when left unattended to. So the question is, at what point do you resolve them? I feel like you can learn so much about a company and their culture by how they handle paper cut issues. It speaks a lot to engineer empowerment and whether engineers have an active desire to improve their product. Like do they just solve it, or make a ticket to do it later? This also applys at a larger scale to things like C++ vs Rust. Rust kinda grew due to all the paper cut issues that accumulated over time with C++. But perhaps this is inevitable and just the nature of software. Like nothing can be perfectly designed in realtime, so adapting to change is the priority. And in things like programming languages you cant really ever undo a decision