-- Winston Churchill if he worked at Google.
1. As already mentioned, the macro system (and the fact that its use is basically required to set up basic monitoring) has quite a steep learning curve. Prometheus doesn't have that and I personally would prefer it did.
2. It's not a service, so you have to set up your own instance, configure it, maintain it. In many engineers' mind this is just another hurdle in front of them launching their service.
3. As a software engineer (particularly new to Google) you might not expect to have to do ops work and carry a pager yourself.
Out of all three, only (1) is a valid reason to hate on borgmon. That and the language itself, which is almost a 1:1 match with Prometheus, are very different from your regular programming language. But given the choice between flat, simple metrics (which is what most monitoring systems give you) and the ability to have arbitrary dimensions and be able to work with them to build useful alerts and dashboards and troubleshoot quickly, I (again personal opinion) will always go with the latter.
It's config language is less crazy (Python based) and operates globally.
https://www.youtube.com/watch?v=LlvJdK1xsl4
Edit: Monarch config isn't sane, it's just different and at least not in the crazy languages that borgmon uses.
As for Monarch, it's a very different beast. For one, it stores all its rules in a protocol buffer format, so it's more structured. But then you have to write Python code that generates the protocol buffers and pushes them to storage. It looks similar but not the same as the ad-hoc query language. I wouldn't go as far as calling it sane.
It is also a service and it's optimized for Google's network architecture with datacenter local and global nodes and the language itself is aware of this distinction and some computations are done locally, others globally and so on.
For your local monitoring needs (or even global ones, if you're willing to put in the effort), Prometheus is a solid choice.
I won't weight in on that debate. But you can think of Prometheus as an experiment to decide the issue: it is very similar to Borgmon, but has a cleaner language.
The equivalent easy to setup and use, with ALL the features working out of the box, SaaS standard is https://www.datadoghq.com/ or potentially Google Stack driver if you are on Google Cloud.
[1] https://news.ycombinator.com/item?id=15315028
Disclaimer: No relation to either org.
Such as Prometheus :) Even some teams in Google use it.
Personally I'm very happy that the open source world is adopting something derived from Borgmon rather than something derived from its supposed "replacement".
Borgmon may be dead in the eyes of some people, but I know for a fact that it's still the only thing monitoring core and critical systems.
Most of the problem with Borgmon, IMO, is the cruft that has built up over the decade+, and neglect due to the Google pattern of "The new thing that doesn't work, and the old thing that is deprecated.".
The difficulty at Google is that developers are rewarded for writing new and shiny from scratch, rather than fix the old but working systems.
This isn't always a problem, as some good things can come out of starting from scratch. But sometimes they throw out too many of the good ideas, in an attempt to be fancy and new.
It wasn't meant to be commentary on Prometheus(which I quite like) at all :)
For Google-scale orgs or infrastructure needs. Most everyone else in the world does not need Google scale tools.
Most of them do run their own datacenters, sometimes in numerous locations, they have massive and extremely complex IT systems in place.