I'd argue that cloudwatch is mainly an event source to drive other AWS infrastructure. Monitoring second, which might be why the experience is so sour.
CloudWatch Events is largely solid; I agree with you!
How did that happen? Accident of history:
First, CloudWatch Events was built for internal AWS usage.
Then, CloudWatch was also built for internal AWS usage (EC2 health checks, fed by the event stream!)
Then, CloudWatch was exposed, since people need to be able to configure those health checks and provision them in CloudFormation and such. So, they had this "monitoring" service—may as well slap together a logging dashboard and stuff. (And then forget about that as soon as the MVP is done, because writing their own equivalent of the Elastic-Logstash-Kibana stack was never AWS's intent.)
Then, after SNS came around and there was somewhere user-controllable for the raw CloudWatch Events events to be routed to, CloudWatch Events could be exposed, too. It got the sub-name because they had exposed the higher-level CloudWatch product first.
If SNS came about before CloudWatch, then probably it'd just be CloudWatch Events with a set of suggested "one-click launchable partner AMIs" for ingesting+indexing+searching/analyzing your AWS event data, and no first-party dashboard at all. And "CloudWatch" would remain an internal feature to power health checks without its own branded dashboard; just an unbranded presence under other services' dashboards/RPC endpoints/CloudFormation type hierarchies.
In the end, I really appreciate the ELK stack, and if you can either use ElasticSearch for other things, or have enough logging to justify a cluster, it (ELK) is a great option.