Typical user doesn't need project generation for 10 different IDEs, OS and packages formats with multiple backends and built-in test support. If you drop half of features then I guess it's could actually become a lot more ergonomic, but in this case there likely tools with better support.
Real pain is that a lot of CMake features are badly documented and most of available information is outdated, but this is usual problem at least for open source C++ projects so it's doesn't cause a lot of frustration and no one try to fix it.
Another point I'd like to add here: CMake basically takes to you what autoconf/automake can do (+ 5/10 years of improvement on UX/UI), but it:
a) doesn't use absurd amounts of slow shell code trying to detect features that no (non-EOL) OS has been missing for the last 20 years.
b) is actually reasonably readable. (Ok, m4 is sort of readable, but it a bit weird in places.)
c) is actually better documented (IME) than autoconf/automake. What people usually do for autoconf/automake is just copy/paste another project/snippet. .. hence leading to the 20+ years problem. (I'll definitely agree that the docs aren't great, but that's at least a problem that can practically be fixed unlike the copy/paste problem of autoconf/-make.)
We do, while we're not doing anything crazy, ie. support for 3 major OS (Windows, Linux, macOS), 3 major build-system (VC, GNU make, Xcode), 3 different compiler (VC, gcc, and clang), 7 different product packaging (RPM, DEB, TGZ, Windows, Mac, Alpine, Android), as well all kind of debug / release custom setup.
Real pain is that a lot of CMake features are badly documented and most of available information is outdated, but this is usual problem at least for open source C++ projects so it's doesn't cause a lot of frustration and no one try to fix it.