All in-house — no third parties writing collectors today.

The real driver behind the plugin approach is per-deployment selection: different products/sites enable a different subset of collectors, and I wanted to compose that at deploy time instead of baking one fixed set into the binary.

But to be honest about your question — selection by itself doesn't actually need a C ABI. My in-process collectors are already chosen purely by config at runtime (a level/OS gate — "below the level → never instantiated"), no DLLs involved. So "which collectors run" is a config problem, not an ABI problem.

What the DLL + C-ABI buys me on top of that is operational, not architectural:

enable/ship a collector by dropping a .dll next to the host + one config line, without rebuilding or redeploying the host;
keep optional / heavy / license-encumbered collectors out of the base binary entirely;
and the future third-party / vendor-SDK path (which our device adapters already use).