This is a tooling problem, not a people problem. There's not a language I know that doesn't have at least a tolerably decent formatter and linter out there, and a delightful side benefit of having those in your build chain is the end of style bikeshedding. I find "well, if it means that much to you, you can always open a PR on the style rules," and the knowledge that they'll need to justify their preference - and own all the whitespace PRs, and at least half the merge conflicts, if they wish not to be thought a jerk - quells most folks' desire to fight about their preferred number of spaces or what-have-you.
Without any sort of reliable tooling support for a standard house style, I believe I might well come to regard the kind of insistence you describe as a demand to waste time on pointless busywork. Doubly so, if the person doing the insisting had made no evident effort to find and put into practice such tooling support.
* They should be mindful of all aspects of their work, including docs.
* If I come across code that woefully misformatted, and comments are all over the place, with random whitespace, and zero effort on spelling (in comments or function/variable names), it causes me to think they don't pay attention to details -- that they don't care about their code. I find badly formatted code to be especially jarring with UI engineers, who should have some knack for visual quality.
* I warn them that when /others/ in the company see our code and docs, if we look sloppy, they will implicitly form a judgement of us as a sloppy team.
On the other hand, if the single contribution I ever provided for my team was spell-check... then yeah, I should leave.