* No standardization or opinionated design, so you can't share your work easily.
* No sane defaults, so your build system is always fragile, difficult to maintain, and done wrong.
* No best practices, so people keep making the same mistakes over and over.
* Misguided attempt to remain compatible with the steaming pile of legacy they've accumulated over the years.
* Bad documentation, so there's no way to learn how to do things better.
* Steep learning curve with limited payoff, so most people don't bother.
Meson does some of these things better. It's still not pretty, but it's nicer to use than CMake.
You forgot to mention that the language is awful (but that usually doesn't get in the way IME).
The answer is that CMake is mad and full of gotchas. Think of it like the PHP of build systems. Here is a classic example:
https://cmake.org/cmake/help/latest/command/if.html#variable...
CMake actual gotchas I dislike enough to avoid it as much as possible include defaulting to cached information, even after I make changes, and preferring "smart", opaque and even hard to track down scripts to explicit user input. It seems optimized for cleverness and conciseness, at the expense of reliability and required user effort.
It's good to have tooling and IDEs for CMake because CMake is complicated and hand-editing the files is very tedious. But if Meson eliminates the tedium of CMake by providing you with different abstractions then you don't actually need the IDEs or tooling.
I have not used Meson, but other build environments (e.g. Make) don't interact as well with IDEs as CMake does (with the exception of premake, which is mostly dead.
No, that's the wrong question and one that's only purpose is to deflect attention from its shortcomings.
All build tools need tooling because if they are adequately integrated into development workflows they are transparent and easy to use. Cmake meets that requirement, and until other alternative build systems do then they will always be far more complicated.
Another poster has explained the IDE support is about IDEs being able to parse CMake files, and I can say that back in the day before CMake IDEs would parse the C/C++ directly using a compiler to output an abstract syntax tree that they would use. So for example Eclipse has this notion of "Build configurations" which allows you to control how this parsing occurs and which files the parser considers valid and what symbols are predefined. Which is IDE support very much like you're looking for from CMake. I worked with it for several years at my last job to provide support for other engineers working with a Make-based build system.
C++ really benefits from it. ctrl+click on a symbol is much more sane than (re)teaching Argument Dependent Lookup rules to all of the engineers in your organization.
You are very fortunate if you import libraries that just work. This is also true for "modern" CMake.