This is such a low-effort blog post:
1. It's click-baity. From the headline you'd think it would be a discussion about why engineers hop jobs so frequently, why in particular FAANGs seem to be so attractive, and what we could do to increase retention. Instead, the post just quickly summarises what we've known for ages (turnover is a big problem), very briefly goes off on a completely irrelevant tangent (that it's more likely for an engineer to change the company than to be hit by a bus, which is true, but pointless) and then tops it off by the insane suggestion that "just use Rails" is the answer to all of your turnover woes (more on that below).
2. There is an interesting discussion here to be had: why exactly do companies suck so badly at retaining talent? My take on it is that we all (companies, developers, etc.) routinely emphasise the wrong things (office perks, showing off tech skills, etc., instead of a good understanding of the product) and burn people out, but as said: this is a much larger discussion. More importantly though I disagree with the received wisdom that "developers are developers" and domain knowledge is worth nothing. Of course, you always should be prepared for the worst (i.e. the proverbial bus), but it should still be the companies' priority to retain good people as long as possible because once somebody leaves, so much knowledge just goes to waste and has to be reacquired. At my last company, my whole team was fired because they thought that some other team would be just as good for the product, ignoring the fact that we'd built up the product ourselves and all the knowledge for two years. But to the higher-ups, the view was that developers are exchangeable.
3. The author just really comes across as immature and uniformed with their unilateral praise of Rails. I've worked on Rails apps so messy that they were almost impossible to understand. And, by now, Rails is by far not the only framework with strong conventions and a lot of out-of-the-box support for many common things - Spring Boot for example (whatever its faults) arguably supports even many more requirements. But more importantly, for any kind of non-trivial app, the complexity is not just in the technology: it's in the (often contradictory) requirements, the different architectural tradeoffs, the little gotchas, the personalities in the team, etc. etc.