The trick isn't to convince, it's to just do.

How I approached it for an org with 300 projects and 10k+ failures after adding the analyzer.

1. Add .editorconfig and analyzer anyway

2. Ignore all the failing analyzer rules in .editorconfig

That's your baseline. Even if you have to ignore 80% of rules, that's still 20% of rules now being enforced going forward, which puts a stake in the ground.

Even if the .editorconfig doesn't enforce much yet, it allows incremental progress.

Crucially, your build still passes, it can get through code review, and it doesn't need to change a huge amount of existing code, so you won't cause massive merge issues or git-blame headaches.

3. Over time, take a rule from the ignored list, clean up the code base to meet that rule, then un-ignore.

How often you do such "weeding", and whether you can get any help with it, is up to you, but it's no longer a blocker, it's not on any critical path, it's just an easy way to pay down some technical debt.

Eventually you might be able to convince your team of the value. When they have fewer merge conflicts because there's fewer "random" whitespace changes. When they save time and get to address and fix a problem in private rather than getting to PR, etc.

Generally it's easier to ask forgiveness than permission. But you've got to also minimise the disruption when you introduce tooling. Make it easy for teammates to pick up the tooling, not a problem they now have to deal with.