"We are fond of talking about the HOWL stack: Hypermedia On Whatever you'd Like. The idea is that, by returning to a (more powerful) Hypermedia Architecture, you can use whatever backend language you'd like: python, lisp, haskell, go, java, c#, whatever. Even javascript, if you like.
Since you are using hypermedia & HTML for your server interactions, you don't feel that pressure to adopt javascript on the backend that a huge javascript front end produces. You can still use javascript, of course, (perhaps in the form of alpine.js) but you use it in the manner it was originally intended: as a light, front end scripting language for enhancing your application. Or, if you are brave, perhaps you can try hyperscript for these needs.
This is a world we would prefer to live in: many programming language options, each with their own strengths, technical cultures and thriving communities, all able to participate in the web development world through the magic of more powerful hypermedia, rather than a monolith of SPAs-talking-to-Node-in-JSON.
People certainly unify their stack on JS that way. For Contexte their team was one React/JS dev, two Django/python, and one full stack. So they had two and a half people writing python and one and a half writing Javascript before, then three python developers after.
Switching to JS would require a full backend rewrite. The backend devs may not do well with the switch, so they may have let go two developers and needed to hire a new JS dev. The presenter may have been let go with that approach, clearly not ideal for the person driving the project.
You'd also need to address the perf issues. htmx clearly sped things up. Is the alternative JS SSR?
Move to a JS backend and now every dev on the team can write client and server side code?