I'm in the opposite camp, runtime reflection is useless, and almost always points to a design flaw while compile time reflection is actually useful (for obvious things like automatically building a serialization layer or an UI which represents the type, or building types from other types).

I'm sure that C++26 has implemented it in a way which is highly unpleasant to use though ;)

The element of runtime reflection that is the most useful is something along the lines of "here's function, here's a list of arguments, go call this function with those arguments".

Having to do this by reflection is a problem in principle solvable by types. Here is a function of type (A, B, C) => R, and here is a tuple of arguments of type (A, B, C), go call this function with those arguments.

Most programming languages make it hard to easily express those constraints so reflection is used instead.

Compile-time reflection is by far the most useful

It replaces the plethora of code generators that currently surround C++ like flies

We have add decent AOT compilation in Java almost since 2000, with Excelsior JET being one of the first vendors to offer it, but few are willing to pay for such tools.

Also I consider ART, GraalVM and OpenJ9 decent enough as free beer AOT.

You can build runtime reflection on top of compile time reflection, it's impossible the other way around. Compile time reflection is a superset of what runtime reflection can do.