These days Ruby on Rails is fairly orderly as well.
https://www.wyc.io/posts/just-build-it-in-django-or-rails/
It's just really hard to beat the reliability, community, ecosystem, and features that are table stakes when using a competent web framework.
When you're poking at a new market, you really don't have time to give a shit about writing CSRF middleware. That's one less customer interview or feature request to grow your business. I'm sure you can do it, and no one's doubting your capability to do so. But these are just things that are tricky to implement and takes everyone time and effort to do so correctly.
And secondly, some of the features you list the frameworks as having are questionable at best. Rails has built-in user accounts, permissions and admin interface? Since when? And action cable is a great example of everything that's wrong with Rails - kludge together a frankenstein solution to tick a feature box. I do not know a single production user.
I think you confused the two messages of "don't build your own web framework" (I heartily agree) with your assertion that a startup in 2017 would be somehow remiss to not be using frameworks developed in the time of Windows XP, with which I do not agree.
For me the current "Rails in 2006" framework is elixir/phoenix, and for the slightly less adventurous, something in nodejs - maybe meteor or plain express. Of course Rails still works, and is not an absolutely horrible choice, but it's for last decade's web, and has profound disadvantages compared to today's technology.
However, for new business owners who don't care so much about getting an A+ for technical excellence, I would still stand by this advice. The benefits of technology maturity and ecosystem are extremely compelling.
Today, for someone who just wants to let their users log in with Facebook, Elixir has far fewer user-friendly resources and will require more technical expertise to produce the same result. How many StackOverflow questions address common woes in these popular frameworks as opposed to the up-and-comers? How easy is it to hire someone to build + maintain? What about for hiring on the cheap? What existing libraries and integrations exist?
Of course, these things get better for new technologies over time. Until then, I can't tell people to use them if it incurs a disproportionate cost to achieve the same return.
Lastly, that "it's old" is not a compelling reason to me to recommend something else. GNU/Linux was created in the 90s, and it's still everywhere and growing. There's a job for an operating system to do, and GNU/Linux solves it well enough for the amount of effort required to use it. I believe the same to be true for Django or Rails in building a fast business prototype for most enterprise or consumer use cases. I think measures of suitability for the task are more relevant than age.
For the use case you're describing, I agree completely with your comments. Perhaps a useful razor is - if you can't state specifically why you can't use rails (and don't say "it doesn't scale"!) - then use rails. I concede that 90% of the time, this is probably the case.
And yes, harping on about its age was silly of me. Age does not inherently mean anything. I'd use postgres (1984!) over mongodb anyday. And erlang is older than ruby. Right tool for the job is far more important, thanks for pulling me up on that.
All that said - I still think that categorically stating "use boring technology" or "just use rails" for absolutely any new project is harmful. New technologies are not always just about the new shiny, they can provide capabilities and functionality simply unachievable with the old. Look at what you can do with concurrency with phoenix. Look at what you can do with react native. Roundly writing off the whole idea of using this new tech as "magpie development" is just lazy.
The whole point of ActionCable was that it is being used by Basecamp: https://medium.com/@dhh/rails-5-action-cable-demo-8bba4ccfc5...
And it's particularly irrelevant if the front-end or back-end is weighted more heavily than the other in terms of product value, when you might hire distinct rather than "full stack" devs someday.
1. Your devs can always go to where the work is - if you divide FE/BE and suddenly you have a feature that needs a lot of BE dev, you can move people from the now-mostly idle FE team rather than try to hire them
2. You can share business logic between FE/BE for client-side functionality. I've seen a surprising amount of bugs that boiled down to "oh we updated code on the back end but forgot it surfaced somewhere in FE code as well and didn't update there"
Of course, YMMV and this probably highly depends on your project, architecture, quality sensitivity, etc etc. But to say sharing FE/BE languages has "no real upside" is a bit... optimistic IMO.
In practice, Point 1 isn't too realistic though:
Front-end and back-end almost always use different build/debugging tooling, different unit/integration testing frameworks, and even different paradigms. Unless your developers are good at constantly switching modes, it's hard.
"no real upside" is wrong, as you point out, but I would stand by "no guaranteed upside" :-)