As far as security is concerned, it's the application's responsibility to properly scope websocket connections... if and when that's appropriate. This is true of any websocket connection, not just those used by StimulusReflex or even ActionCable.
As noted by the parent, latency is certainly a consideration when using such tools, but there are a myriad of libs and techniques that can be leveraged to help you build great user experiences with StimulusReflex and LiveView. You just need to consider your options and architect accordingly.
Note also that the expo demos for StimulusReflex are incredibly old (a few major versions behind at this point) and were created in haste to help people grok concepts via example. They were never intended to be a canonical guide of how to best architect such apps at scale. We're considering taking the expo site offline in favor of more specific and better architected demos.
This is exactly what CableReady was built for... to update the DOM from any Ruby process (in the request cycle or not). It was designed from the beginning to update the DOM from out-of-band non-request based workflows like background jobs.
Interesting point about grassroots vs top down. I think that definitely plays into the equation. Another big part of it is that developers seem to a unique class of workers that don’t seem learn much from those who preceded them. We love to reinvent things, in part due to the snowflake effect & NIH syndrome. The other reason I think the wheel keeps being reinvented in tech is due to the developer workforce essentially doubling every 5 years... also, the sad reality that ageism coupled with very few long term viable career tracks available for software writers pushes a lot of experience and wisdom out of the industry.
I'm not sure any other technology stack would have fared much better.
Consider that 6 years, 2 months, and 20 days passed between Rails 3.2 and Rails 5.2. That's quite a bit of time for the framework to evolve. Then factor in the customizations from several non-framework dependencies and those added by GitHub.
This is an incredible achievement no matter how you slice it.
Our tools & materials are constantly changing... not to mention that every project is different in various ways (though many developers delude themselves into thinking their project is unique i.e. the snowflake effect). I've found the most success when I stick to tools/patterns/strategies that I've had some degree of success with in the past.
Conway's Law & micro-services help maintain flatter organizations at least in tech focused companies. When disagreements arise & consensus is hard, the various parties can simply introduce a new service boundary & go their different ways.
I do like the access-granted DSL. It seems to address some of CanCan's problems on larger more complex projects. Also... if you prefer a more OO style, I wrote a 50 line authorization lib that has proved workable on some of my larger projects. https://github.com/hopsoft/perm