Ah sorry, I should have clarified in my original message. The page I linked to is our public marketing site, which is a static site built with Next. The Phoenix application is the product that the site is talking about (Duffel Links).
I wasn't personally involved in making this decision, I was brought onto the project after it was taken, but there was a perception that we'd be faster if we did everything as a full-stack application. In fairness, we did deliver what we set out to do so it was a success, even if there were some rough edges to deal with.
Also bear in mind that I'm only covering my front-end perspective on this. I think the back-end developers involved on the project found it much easier to work with as they were already experienced with Elixir and Phoenix. For them, a tightly-coupled front and back end meant that they could change the way things worked and it was straightforward to update a few functions in Elixir and then the HEEX template, as opposed to a decoupled setup where we'd probably have been communicating using a JSON API and changes would have had more of a barrier to adopt.
I've been using Elixir with Phoenix and Liveview at my job for the past three months as part of a small team building a non-trivial web app (https://duffel.com/links). I'm mostly a front-end developer and was brought in to handle the UX side. Prior to this project I've spent the last 5+ years in the React world.
I found a lot of what the author says to be true. I'm used to the nightmare that is managing front-end dependencies, and it was refreshing to use something so 'batteries included' that comes with most of what I need.
It took me a while to get my head around the Phoenix + Liveview way of doing things, but when my mental model clicked into place and I stopped trying to do things the React way I became a lot more productive. When I had an autocomplete updating live as the user typed all going over the websocket without me writing any JS, it felt magical.
However I definitely found a lot of sharp edges that the author doesn't mention. We struggled a lot with any non-trivial UX, for example with the autosuggest mentioned above I had to add a lot of JS to handle things like being able to use the keyboard's arrow keys to select options. Whenever I jumped into the JS world it often felt like I was fighting against Phoenix, and had to resort to using 'phx-ignore' a lot. It was frustrating to continually struggle to do things I knew how to do easily in a pure JS environment.
Another area I struggled a lot is Elixir's syntax. To me, it feels like there are too many operators. The author touches upon it towards the end when they mention things like '\\' for default arguments, '<>' for joining strings and '++' for joining lists. It's a lot to wrap your head around at times.
Some of the fault for this lies with me; we were working to a tight deadline so I didn't have time to dedicate to learning Elixir, Phoenix and Liveview from first principles, I just jumped in out of necessity. Had I spent more time on the foundations first I may have been able to avoid some of these pitfalls, but I do think it illustrates that like many 'do everything' frameworks, there's a steep learning curve to doing non-trivial things. It's a powerful tool and I'm optimistic about its future, but I'm undecided if I'd choose it for a future project that has significant front-end requirements at this stage.
I wouldn't say I'm a prolific blogger; maybe 4-5 posts per year, but it's nice to have a space to post any thoughts I have.