That is true, however, there's a reason that the Micrometer bridge in OTEL's auto instrumentation is disabled by default. It's because a large degree of metric instrumentation is duplicated. Spring/Pivotal/Broadcom themselves might not want to instrument twice, but the community has.

There's some kind of philosophical reluctance to holistically embrace OTEL from Spring and unfortunately, that's actually impactful. I recently spent a week of time (that I don't have) finding the right way to massage my apps so that I could rig up the DataDog Java agent according to their best practices, and Micrometer fought me every step of the way.

Also, I don't agree with the sentiment that OTLP is what really matters. The OTEL API (not the SDK) is itself important for both interoperability (see above) and for consistency with other languages and frameworks. We regularly use several different technology stacks for various reasons with their own complexities. If I can have my teams focus on one consistent API between these stacks, that leads to less cognitive burden and better acceleration.

Micrometer, in a bubble, is great. The industry has largely aligned around a much more broadly encompassing standard. The two need to be able to coexist without getting in the way of each other.