The official docs are too sparse to be useful to me and the results of googling mostly give stale advice.
I also have being easing into CMake recently - I was initially impressed as getting a "hello world" example was simple and the CMakeLists.txt was clear. As the project has progressed - simple additions like unit tests, external dependencies, specific aspects for debug builds, handling basic cross platform differences, etc. have made the CMakeLists.txt almost unreadable and really quite brittle.
I'm not quite at the stage of abandoning it but I have wondered whether an old fashioned Makefile wouldn't be simpler. At least there is a logic, if convoluted, to make and the documentation is top class. CMake seems to lack a clear design and just seems like hack on hack but this could be my ignorance.
I've no real idea of what I'm dealing with when working with CMake - it's wears declarative clothing but actually it isn't at all. The ordering of CMakeLists.txt is significant and you have to be aware of whether what you add will be "executed" during cmake or gets executed with cmake --build.
Those things you mention - cross-platform differences, unit tests, debug builds etc. - require a bit of getting used to, but once you do, the syntax is not bad and I don't feel I'm suffering. Certainly not feeling the brittleness.
And - no, an old-fashioned Makefile can't even _begin_ to cut it. Not by a long-shot. (And that's not even mentioning the fact that it's mostly irrelevant on Windows.)
Nobody really wants to focus too much on build configurations when working on things, they should 'just work'.
And CMake, although I am using for a long time already, is not the offering this 'just works' experience I am afraid. It is so easy to introduce side-effects, and figuring out the intended way to include a project can be a big pain when documentation is sparse. Sometimes I wished I had a CMake debugger. And with modern CMake I feel like this got worse to some degree.
For now, the situation is that if you invest in your CMake - blood sweat and tears - then the build itself will "just work" on many/most/all platforms. Which is already pretty good - compared to being stuck with Makefiles.
Also, CMake is essentially its own debugger, because almost all state is just a bunch of string variables.
1. Small projects also have dependencies
2. Small projects need to be build on multiple platforms too
3. It is more verbose, and at the same time more obscure, than writing a CMakeLists.txt (typically).
Something I've noticed is that there is no such thing as a single good introduction:
* CMake itself is changing. While the "revolution" of modern CMake is upon us already from version 3.0 (or a little earlier), a bunch of thing change with versions 3.12, 3.13 etc. See: https://youtu.be/y7ndUhdQuU8
* Different treatments - a mini-website, PDF presentation or conference video - focus on different aspects of work with CMake, but you probably need most or all of them in focus in order to actually do what you need done. That's how you can see videos entitled "More Modern CMake" and "Oh No! More Modern CMake"...
* Setting up the CMake machinery to have your repository/project installed is the opposite of straightforward, and very easy to get confused about.
* There are a half-dozen different ways to have your project depend on on other code: External projects, package management CMake modules, relying on other projects being installed in a CMake-idiomatic way and then find_package working, and more. Regardless of which you think is the right one, you'll need to live with others doing something else.
So, do follow the link, but don't expect it be sufficient.