There are a lot of reasons to move to client side templates but virtually all of those reasons go away in a BEAM environment.
Let's start with the biggest one: template performance.
When you benchmark the template rendering in Rails, Python, etc usually you find that the View layer accounts for well over 50-60% of the request time. That's because for the most part these systems are creating new string based output that needs to be sent back to the client which means allocating and cleaning up lots of RAM.
Within Phoenix, each snippet of text in the template exists in memory exactly one time. The rendered template never even exists on the server, it simply loops through a list of parts to stream back to the user's connection, injecting variables where needed. In my own testing (and testing echoed by many shocked people) this approach will border static file performance. Most people avoid caching entirely within Phoenix applications.
Here's a detailed write up if you're curious:
https://www.bignerdranch.com/blog/elixir-and-io-lists-part-2...
And here was my own experience:
https://www.brightball.com/articles/insanity-with-elixir-pho...
Next up is payload isolation. One of the big pushes for client side rendering (outside of interactivity) is the ability to make separate async requests to different APIs in isolation to avoid the sequential loading bottleneck.
BEAM languages are designed for millions of asynchronous calls at once without overloading the system and as a result this means that you can easily make all of those async service calls on the server side within a single HTTP request.
The combination of these two characteristics is what makes LiveView possible in Phoenix, where it's really not a feasible exercise in most other languages.
https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
Because of that ability to handle so many async processes, it also create an ideal environment for websocket based work along side standard HTTP based projects.
Client side applications tend to account for this by storing data within the browser to keep a running log, but Phoenix channels create the ability to maintain user state in a dedicated process for each user's connection...rather than in the browser or a server side data store. Aside from extremely data heavy workloads in browser, this eliminates the need to store data in the browser and makes it simpler to sync data across multiple browsers, devices or applications.
And this improves further with the ability to expand an elixir cluster horizontally without the need for a central data store to help those web servers communicate.
The author isn't exaggerating when he promotes Phoenix as a premium option. There are things you simply can't do in any language that has a shared memory model. The BEAM capabilities create an environment where layers upon layers of complexity just, go away.
Including the need to depend on client side templating.