I don't think you're missing anything, but I think you (as many have before) are forgetting about one of Rails earliest and biggest selling points: curation of best practices for creating specific kinds of applications. While the ease with which skilled practitioners can configure the framework to work well for an API-driven application is a testament to its flexibility, the out-of-the-box conventions have been in need of some love for awhile.

I don't think this is a huge deal, but it will definitely be nice to have official support for this configuration.

DHH talks about this in The Changelog #145 (2015-03-06) starting ~01:14:15.

https://thechangelog.com/145/

This is good, DHH basically is talking about making rails (in the future version 5ish) more flexible for all those people building just backend rails apis that are consumed by seperate client frontends, mentions integrating websockets too. So it sounds like this is the first step in that direction.

There's a lengthy explanation here: https://github.com/rails-api/rails-api#why-use-rails-for-jso...

EDIT: sorry, I mis-read your post. This is just "Why Rails and not Sinatra," not "this is easy enough to do on its own, why bother."

I wasn't directly involved in the decision, so I cant' tell you, to be honest.

this justifies the library's existence but does not justify it's inclusion upstream.

Because Rails has become bloatware and has been since they lost sight of the future of the web and stagnated on innovating...