To put it another way:
When a class is loaded, the static initializers are called before anything else, as you already know. So if a class's static initializer throws an unchecked exception, then the attempt to load that class has failed. That means that you can't subsequently call static methods of that class, and you can't create instances of it. Basically the class is useless after that happens. You would probably want to log the error and terminate the application, but I suppose the SO comments about being able to unload the class in some circumstances might be relevant. However that presupposes that you can subsequently reload the class without the same unchecked exception being thrown, which means that your code would have had to catch the first unchecked exception and fix the problem which caused it to be thrown.
I suppose that situation might exist in some design somewhere, but in my opinion it would be better for that "catch the unchecked exception and fix the problem" code to be part of the static initializer, thus making it unnecessary for the static initializer to throw an (unchecked) exception unless the problem is really unfixable. So then unloading and reloading the class would be unnecessary.
Anyway I'd have to say that describing the process of having a static initializer throw an unchecked exception as "a bad idea" is unhelpful -- unless a better idea is proposed. That didn't happen in the SO thread. So I'd reject that and say that if you can't load the class because a static initializer fails, then throwing an unchecked exception is your best option. Yes, that probably means your whole application is going down, unless it can continue without the failed class, but chances are there's nothing else you can do.
Of course it's also possible that the class which can't be loaded isn't a critical part of your application. Maybe it can continue, with that class's features disabled. In that case throwing the unchecked exception would be a perfectly reasonable design.