Your idea of centralizing things into a module assumes you have control over all code ever written.
This might be true for the 90% of Haskell that is created and abandoned by PhDs writing their theses, but if you look at other language communities: People like to use a library from time to time.
You're being deliberately obnoxious in your phrasing. Cut it out.
Regarding your content:
You are making (or missing) a point I made above, and moving goal posts.
If you are writing a library that defines a new type and would like to provide an instance of some classes, there is no problem, those are not orphans.
If you are writing a library that defines a new class and would like to provide an instance for some types, there is no problem, those are not orphans.
If you are writing an application, the approach I suggested for the context of working on an application is entirely appropriate - you write orphan instances, and have a static check that they are coherent.
There is a bit more trouble if I am a library wanting to provide an instance of a class that I do not define, for a type that I do not define. Allowing orphan instances in this case, with or without a static check for coherence, assumes consumers of my library "have control over all code ever written" - it will either be dangerous (without a check) or forbidden (with a check) that they use my library with (potentially seemingly unrelated) libraries. The correct workaround is usually to provide a newtype, for which you can define non-orphan instances. This is not bad, but it certainly is a bit of a tradeoff.
But again, you moved the goal posts. I made no general claim about the suitability of Haskell's expectation of coherence. I objected to your false claim that maintaining coherence involves picking over spurious warnings about orphan instances. It does not.
This might be true for the 90% of Haskell that is created and abandoned by PhDs writing their theses, but if you look at other language communities: People like to use a library from time to time.