From my experience, if you work on C++ codebase large enough that indexing it is a problem, compiling and linking it is a problem of the same order. And as you need beefy hardware to compile and link your code anyway, you can reuse the same hardware for indexing and editing.
Sure, VS Code + LSP may be dog slow on a typical "power consumption-optimized crappy business laptop" like T-series or X-series ThinkPads, but on such hardware, even if I had fast code editor, it'd be a pain to develop due to very long compile times anyway. And on a 12c20t workstation with 64 gigs of RAM any editor works like a charm. Yes, `clangd` eats 20 threads and 20 gigs of RAM for indexing, but go to definition works instantly, and I don't really care about hardware resources.
Then, parsing C++ properly is really hard. Even JetBrains had to admit it as they've integrated clang++ frontend into the CLion. I don't believe that one person can create both a good code editor and a fully compliant C++ parser. Maybe they piggyback on EDG or clang++ frontends, but from their website it seems that everything is written from scratch.
Another problem I see is that very few of large codebases are C++-only. Usually it's some C++, some Python (or Perl, if the code is old enough) scripts, maybe some Java interop code, few Go tools, with a bit of Lua on top. And a lot of make/CMake/whatever build system files. "Big" IDEs and editors either support all of that from the box or have plugins to fill the gaps. I don't know if the paid-only closed-source product can gain traction big enough to have a vibrant plugin community.