That said, it can be fundamentally hard to strike a balance on that with a client.
>Should a client need [...], I'll go with it. But I'll do so only when it's the simplest and most maintainable solution to the problem, and not because I want to be the greatest of programmers in my or other people's eyes.
"Simple" and "maintainable" depends on who is maintaining the project after you, and what they know, and what programmers at-large are likely to know. I also tend to make frontends that heavily rely on server-side and jQuery. I know that an SPA might be better sometimes, but since it will take me 10 days to learn a new framework (say 30-90 to learn it well), it's never the simplest solution _from my perspective_. But, it might be fine to stick to my old ways if the client just wants speed, or if I know I'll be around for a while, or if I'm confident any newbie can come in and quickly understand/overhaul my work.
I think it's also just ok to admit to ourselves that, even if it's not ideal for a client, eventually we want to work in a way that's mentally comfortable and familiar. You want some adventures to spice things up now and then, but too much too fast is overwhelming. Wanting to work with a familiar stack seems comparable to wanting your usual snacks, noise level, view, temperature, etc. As we become less desperate for salary, or as priorities change, it ideally becomes easier to say no to jobs/clients that can't accept a certain stack.
Your point on mental comfort is also spot on -- ideally, there should be a satisfaction between developer comfort and fulfilled clients. Sadly, that could also come with its own compromises. Heh, development is fundamentally a game of figuring out the sacrifices with the least impact for all parties involed.
