Indeed, I don't like Black's style, but I prefer working in a Black codebase than one where everyone has their own preference. Having style guidelines in a team is also a great way to remove pointless debates when reviewing PRs.
...which is why I wish Black allowed more configuration. A team can often agree on a set of styles. Every team on the Python planet agreeing... now that's much harder
Black is opinionated, so it skips the debate entirely. We just use Black, not black with 120 characters lines, just Black.
To each their own I guess, but to me it just seems like pandora's box. Once you show that you are open to changes in the linting configuration, it makes the rules mutable and pretty much guarantees that at some point someone will say "how about we just change this one parameter in the linter", which will probably be agreed by the rest of the team, not because they actually agree but because they don't want to argue.
gofmt is also opiniated. Someone somewhere picked the defaults and maybe I disagree with those defaults, but in the grand scheme of things, all go code is more approachable because it all looks the same. That to me, is worth a lot more than having my favorite format be the one on top.
EDIT: If you want to discuss the actual merits of Black, you can read their style page that actually explains every choice they made: https://black.readthedocs.io/en/stable/the_black_code_style/...
What for? Just to be clear even Django itself isn't obviously using a configuration, what makes your team so special they need this?
this usually just means new team members are stuck respecting the wishes of the old-timers