Not an issue for you, that you know of, because you have no equivalent software that's written in a more performant language (or at least critical portions of the codebase written in a more performant language). That's part of the problem; in most cases, software users don't know what life would be like with better software. They assume the performance they see is close to optimal, or at least that the devs made an effort to optimize. Users are willing to get used to whatever the software's performance is, in order to have access to the software's features. You can get used to almost anything, as suboptimal performance turns into background noise, but that doesn't mean you should. You get used to waiting 5 seconds for a piece of software to do something that you do on average once every hour or two, not realizing that those 5 seconds, 10 times a day, 365 days a year, cost you 5 hours every year.

Optimizing performance and fixing crashes/bugs/dataloss aren't mutually exclusive, either. Developers who care less about code quality than checking boxes for features requested by management or customers, will write code that's both suboptimal and buggy.

> Not an issue for you, that you know of, because you have no equivalent software that's written in a more performant language

How on earth would you know that? No, incorrect.