Be careful about that second point. I have seen people posit themselves into positions of critical design decisions only to position the business around their core strengths. That is toxic. It will buy you increased job security for a time, but if your strengths are out of alignment with common sense it’s only a matter of time before you and your team are crushed by tech debt. An example is imposing all business logic goes in Kubernetes because you good at Kubernetes. Be aware that you will likely encounter this at least once in your career.
The second point hasn't really helped me much, I opened a new line of business basically doubling my groups revenue. I spent almost three years trying to convince my boss to stop leaving all sort of money on the floor and actually pick it up. It took a while but then he finally got it and ran with it, the only problem is I am the only one with the skill set to actually do the work, the rest of the group is still living in 2008 and being told what a great job they are doing (IMHO they are ripe to be off shored). Now the wok is spinning up and I'm still the only person that has the skill set but there are no rewards for that skill set aside from management telling me I have to teach everyone what I know (and that's not going to happen)
Incidentally becoming the single point of failure isn't the problem. The problem is an ethics violation of intentionally positioning yourself before the cost and maintenance considerations of the application.
If, in your example, you become the single point of failure because nobody else wants to engage in modern practices to increase the durability of the application then its a management problem. The way to think about that is: that by changing direction are you reducing time and cost of delivery? If so you have become that single point of failure by pushing for greater ethical considerations.
Beware though, everybody especially people who are ethically wrong, will claim their way is better. The differentiator is measurements: speed of delivery, speed of refactor, degree of risk, speed of labor, quantity of dependencies, compile time, load time, and so on.
