There's nothing inherently wrong with the code Doxygen generates or with its C++ parser. I've worked on large projects using crazy Boost pre-processor macros and plenty of C++14 features and Doxygen handled it all fine.
IME the number one problem with Doxygen is that the people writing the doc comments do a poor job. It's garbage in, garbage out.
The Java documentation is great because the people who write it put in a ton of effort to actually explain how to use their API, with examples, hyperlinks to other modules, version information, compatibility issues, and everything else. They're not adding trivial @param and @return comments as an afterthought.
Unfortunately, a lot of Doxygen documentation seems to be the trivial kind that tells you "@param foo The integer parameter foo" but doesn't give any clue how to use the library, class, or method.
That's just the stuff I have readily available; there's been several times where I tried to use Doxygen to figure something out, only to discover that it was horribly confused and worse than useless (since it looks like it can tell you the information, but it doesn't figure it out).
I'm fairly certain that doxygen uses libclang[0] for a correct parse of the code these days. 0: http://clang-developers.42468.n3.nabble.com/Doxygen-1-8-4-us...
If you look at other languages, automatically-generated code documentation has become the main way people ingest documentation for software projects. Javadoc was the first major such tool; if I'm trying to use a Java library, I don't read the source code, I start by reading the generated documentation. If you've ever used https://docs.oracle.com/javase/8/docs/api/, you've used the results of Javadoc. Similarly, Rust also has a widely-used builtin documentation tool (and again, the official standard library documentation is entirely the result of rustdoc).
C/C++ of course don't have a builtin tool. Doxygen attempts to fulfill that same gap, but it also suffers from trying to support every language under the sun, as well as the inherent issues of C/C++ (the use of the preprocessor to generate module boundaries does not make for fun processing). I also find that the default settings tend to make too many graphs that aren't really useful but take up a lot of visual space (I've never found collaboration graphs to be helpful), and its approach to trying to figure out what things are types gets pretty sketchy (why does it think that unsigned is a class?). To top it off, I was never impressed with its design aesthetic.
In short, the fault of doxygen is that it's not designed in close integration with the language parser to ensure a highly correct understanding of source code, which makes it tend to fall over if anything is moderately unusual or confusing. And since the general experience with its output tends to be negative, there isn't much effort in trying to maintain quality documentation comments in the underlying code in the first place.