I think you're undersstimating the added value – the point is that people don't have to bother setting up and maintaining all of those moving parts with a service like firebase.
Case in point, I was building a small real-time web serice this weekend; it's exactly the sort of thing that Firebase would be great for. But given that I couldn't run it locally, and that there's no migration path if they were to acquired and shut down, I had to implement a half-assed solution on my own. If Firebase had been open-source, I'd almost certainly have ended up forking over cash for them to host it anyway.
Just, for my situation, I am not sure why I need to pay for that functionality when I can literally set it up in one day vs reading the documentation on how to set it up on Firebase in the same time.
I also control all outcomes and avoid ones like this where Google could potentially take over control of a large portion of your app.
My server side code is about 100 lines. This controls a chat server, chat rooms, youtube video commands. And its currently working just fine with 4,000 visitors a day on a vps that cost $5 a month.
Why not learn how to do it yourself? Especially if you already have vps. I am using varnish with multiple sites and it took a couple hours to set up. I am really confused on this.
1) Full user management services, including registration and password recovery
2) Extremely fine-tuned access control per resource
3) Complete, tested front-end libraries for AngularJS, Backbone, and other popular frontend libraries.
4) Much more reliability than socket.io in providing cross-platform, cross-mobile real-time messaging (believe me I've used and tested socket.io). socket.io may or may not work on a given platform, and it's no longer a very active project, either.
5) Full admin panel for database, including real-time data updates.
Look, for a chat app, you're absolutely correct that Firebase may be overkill. But very few of us that rely on Firebase for applications are limiting ourselves to chat apps.
That said, I'm not happy about this acquisition. And this is probably the last time I'll be burned like this by a PaaS company. I saved a lot of time by going with Firebase (much more than 100 lines of code) but I'm questioning whether it was worth it.
PS: I didn't downvote, although I was tempted after reading your "Why not learn" remark. I think you're right in the end that open source is the best solution, but you're very wrong to assume that people are using Firebase because they can't quite figure out how to make a 100-line Node app.
Also, check out the number of issues, some of which are pretty significant (although there are tons of ridiculous ones there, too). But if they're catching up -- and they appear to be -- that's great. It's a great project.
Firebase has solved many harder problems than you and I are ever likely to have to deal with and they deserve full credit for that.
There has been lots of movement with the bigger release but nothing that has interested us in going back to it.
We've only needed to handle concurrent connections in the 1-10k range though.
There are really better c++ and erlang implementations we've investigated but won't pull those off the shelf till needed.
Obviously there's loads of great realtime-as-a-service offerings like Firebase and Pusher that make sense for a lot of use cases, just not ours.
We were always uncomfortable with relying on a third party for a core aspect of infrastructure, and this acquisition introduces uncertainty that we don't have to worry about.
 Poxa: https://github.com/edgurgel/poxa