I think a couple factors are at play here. First, most developers never really learn metaprogramming or use it, even in languages with native facilities for it. You don't need it to get the job done, strictly speaking, and it is a difficult skill to acquire. Second, many software applications don't benefit that much from metaprogramming even when you have those skills. The benefits aren't universal, which brings the costs into question.
Nonetheless, for some types of software, writing code without using metaprogramming will have several-fold the LoC, complexity, etc of the equivalent with metaprogramming. But if you never developed metaprogramming skills, you are unlikely to recognize when these opportunities arise. In these cases, you do see large productivity multipliers. I see this pattern all the time in C++; most C++ developers have no idea how much concision (and type safety) metaprogramming enables in contexts where it is perfectly suited for the job because they never learned metaprogramming in C++, so they write vast amounts of brittle boilerplate instead.
I've used metaprogramming in enough languages and contexts to recognize it as solving a broad class of problems in a general way, but you still want to pick your moments because it isn't free. Similarly, garbage collection is the right choice for many software applications but it isn't free and there are contexts in which garbage collection introduces far more complexity than is justified by the benefits.
Recognizing these situations and being able to take advantage of them is a market opportunity.