In Kamal 2, the secrets were moved from .env to .kamal/secrets. Be careful as this file is included in your version control by default (not added to .gitignore).
This will block incoming requests except the SSH port, and ports 80 & 443. For server hardening, I also like updating all of the packages on a fresh install and installing fail2ban. I'll also typically update my SSH config (or verify it) that password authentication is disabled, so you can only use a SSH key to authenticate.
Back in 2010, we had a few options for rich front end interactions. RailsUJS got us a little bit of the way there, but was severely lacking. Turbolinks back then often caused problems with other javascript libraries and was often something that I would disable when creating new applications.
Fast forward to today, and that isn't the case much anymore. Today, with Stimulus and Turbo, we are able to create rich interactions on the front end. Even with Turbo alone (with streams and frames) we can accomplish a lot of rich interactions without needing to write any javascript ourselves. While some may benefit from using a heavier frontend framework like React, Vue or Angular, the benefits are fewer and fewer today than they were back then.
Perhaps if there was a larger company who had a whole department around design and frontend stuff, it could still make sense to use React and the Ruby on Rails side was simply providing an API. But often enough, this isn't the case for small to medium size companies (and even a lot of large ones). I've seen some medium sized companies today that are still stuck in this mindset that Ruby on Rails cannot handle rich interactions and they're still developing Rails/Frontend Framework(Angular/Vue/React) together on the same team and their velocity is slower than had they stuck with what Rails provides today. Another benefit is that there is a vast library of existing components for React that could be appealing to some to use those instead of having to create their own implementations.
Regardless, on a new application, my preferred route is the "Rails Way" using what is provided by default. Over the past several years (ever since Stimulus was released), I lost any desire to explore frontend frameworks and with the release of Turbo, this was solidified.
I've gone down the monolith with Backbonejs, Angular, and React. Using just Stimulus and Hotwire is a breath of fresh air. Though, to your point, it can be difficult when you run into those "edge cases" where you need something to happen that the framework doesn't have available. There is some great discussions about this on this GItHub issue https://github.com/hotwired/turbo/issues/92 as well as some potential solutions.
I've ran across some of the issues that you're describing too. Specifically, when there is something like ChosenJS that you want to have rendered from a Stimulus controller, but cannot invoke the chosen() function because of the whole jquery stuff. Some of the solutions in the link above could help address these issues, but what I've done in the past is work towards moving away from the jquery libraries in favor of something with vanilla JS. However, I can empathize with people who have heavily invested in one JS library that is used throughout their application.
I think your approach is sound in what you'd typically do and this is a similar approach to what I take. However, it does cause some issues when trying to deploy an accessory like PostgreSQL because the private network is inaccessible from the outside. However, you can use a proxy which is what I do. I have a separate VM that is on the same network (could be the web server or another server that is accessible from the internet) and the Kamal deployment comments get tunneled through the proxy. This means that Kamal would have access to the PostgreSQL server through the proxy. I'll then allow-list/white-list the IP Addresses that can access the proxy server to prevent unauthorized access.
