TL;DR: It boils down to the trade-off between having all the components (receivers, exporters, etc.) available in the collector vs having a secure and (SLA-based) supported version of the collector with select and typically way fewer components. If you look at the 20 odd vendors only a handful have their own collector (disclaimer: I'm the product owner of one of those, AWS).
So, you can choose between using the "kitchen sink" (all components available, but you're responsible for security and performance) of OpenTelemetry contrib distro vs. a vendor-provided one (or build your own, it's pretty straight forward thanks to the awesome tooling the community built).
My recommendation: use the upstream otelcol-contrib
collector for experimentation (I do that on a daily basis) and have a clear strategy (either vendor provided or roll-your-own distro/collector) for prod, with all the implications around support. Think for example of the impact the log4j vuln had last year and you get an idea how a 150 times more powerful agent can cause ops pain.
Some data points: I ran an OpenTelemetry survey this year (results available now via mhausenblas/otel-adoption-survey-2022) that shows ca. 50:50 split between upstream on the one hand and vendor/DIY on the other hand.