I think the main reason, as discussed above, is to simply leverage the communities of these platforms and possibly get an MVP out the door much more quickly. Sure, perhaps a Craft-based solution might not scale as cost effectively as a homegrown solution, but I would be interested to see financial statistics on how they compare, if such statistics exist.
On another note, I spent some time in the Meteor community before they pivoted the framework to where it is today (React + GraphQL) and back then people always raised scaling issues with regards to Blaze (the templating library) and its performance and how Meteor managed realtime with MongoDB (they were tailing the oplog; operation log, and doing complex data diffs on the server before pushing updates to the clients instead of just handling it all in the service layer, which would’ve been a much better solution; see Feathers.js) and the community leaders constantly said - scaling isn’t an issue and if it is, then it’s a good problem to have. The other side of that debate was that as soon as you hit scaling issues, you either threw money at the problem (a basic Meteor app easily cost much more to run than a Laravel, Wordpress, Craft etc. based app to begin with) and when money could no longer help with scaling issues, you began to strip out Meteor altogether. Food for thought for sure.
Another avenue I’m exploring is utilising Firebase. You get realtime & easy, CDN deployments for a very reasonable price and since they’ve been bought by Google, they now offer Google storage and are beta-testing Firebase integration with Google Cloud Functions for when you really need a backend process (much like AWS Lambda). Having all of this functionality under one roof might be beneficial to some and help get to market quicker or simple get an MVP out the door quicker.