IMHO - I think it was just a matter of the wording. I believe what the author meant is that if you were to deploy to something like Heroku, you may not be able to take full advantage of some of the OTP features because 1) they will restart your apps daily (losing any in-memory state in the GenServers), 2) dynos are firewalled off (unless you use private spaces), meaning nodes cannot talk to one another, so moving one OTP app off to a different server becomes a challenge. 3) You’ll also likely not be able to take advantage of hot code upgrades, nor will you be able to use observer since a remote shell is ephemeral and not on the same node as the app.
That said, you absolutely can successfully deploy an Elixir/Phoenix app to Heroku and even connect the websockets using a shared Redis…it’s just not the same as on raw VPS, EC2 or GKE…but for many web applications, its fully sufficient. There’s also Gigalixir, which gives a bit of a middle ground with the no-dev-ops solution, but tailored to Elixir/OTP.
So, I don’t think it was intended to be a knock on OTP at all, but just that there is more to consider when picking a deployment strategy when you use an Elixir app than something like Rails or Node if you want to be able to take advantage of everything OTP has to offer.
As for the rest of the concepts, they seem solid for the most part. It’s very easy to fall into the trap of introducing too much coupling and two-way dependencies, especially if you are coming from a framework such as Rails. That said, I personally would probably use this as more of a guide than a scaffold generator. I think it is important to still know whats going on underneath, how the parts interact, and be able to stay current with each without depending on the author to update the scaffold generator in a timely manner…but that’s just me.