There are plans to migrate the proxy -> mixer pipeline, but in a mechanism slightly different than you outline here. There is a proposal (and ongoing design / poc work) to move mixer entirely into the proxies.
That being said, Mixer does not use the metrics service API for a few reasons. Mixer takes a more generic async
Report that consists (mainly) of attributes and their values. Mixer then uses operator supplied config to transform these Reports into instances of various types (metrics, logs, traces, network edges, etc.).
The key distinguishing bit here is that Mixer wasn’t (initially) designed to ingest pre-formed instances. Consuming already formed instances removes operator control (and/or requires a mechanism for editing fully-formed instances). There was a proposal (and some initial PoC work) around adding a “Direct” API to Mixer to support ingest of pre-formed instances, but that work hasn’t been done. There is hope of supporting it in the new architecture.
It looks like while I was typing this Kuat covered another reason for the difference.
I don’t know if this fully answers your questions or not, but I’m happy to discuss further at any time. I’d love to hear more about your use case and your consumption of the metrics service API.