Users should never see assertion errors (uncaught exception in
general) and therefore the assertion message does not need to describe
what went wrong.
In a lot of contexts, assertions are best used for spotting bugs (programmer errors) -- things that should never happen. They're ideally caught in internal testing before they reach the hands of the user (and often serve that purpose of spotting more issues upfront during internal testing instead of leaking the issues to the users). They're different from exceptional control flow which is typically the result of an external error outside of the programmer's control (trying to load a corrupt file, e.g.) and not actually a bug.
In the unlikely (but not always impossible) event that they can and do end up reaching the user, it should be obvious what kind of assertion failure message looks less horrid to an ordinary user.
Is there an additional explanation of which type of assertion messages
is better or why both types are unnecessary (other than personal
Maybe it'd help to run into more assertion failures?
As an example, I might run a debug build of an application in a team environment after acquiring new hardware and drivers and run into an assertion failure like:
"Failed to allocate vertex buffer object!".
Aha! Instantly I know the problem is in the GPU code. That might not even be my responsibility, it might be Fred's code. Now I can just bounce the issue to Fred without even studying his source code.
If I'm in control of the code, it still tends to give me a lot of information about what happened at a glance which can be quite soothing.
The alternative with comments is to dig into the source code, to the exact line of code and source file in which the assertion failed, and then read the comments, with an assertion failure message like:
Assertion failure in some_path/something/some_source.ext: 119: assert(success).
And even that little moment of suspense where you now dig into that cited source file and go to the specified line number to try to figure out what the hell happened can be quite stressful, especially since assertions are never supposed to fail (but still do sometimes anyway, making them really unpleasant surprises).
In general it's a lot more stressful to me if I enter my apartment with the lights off and people just start yelling "RARRRRRGH!" at the top of their lungs before singing happy birthday. It's far less stressful if they skip that part and just start singing happy birthday. "Phew, that's why they surprised me!"
I'd say it's quite a stress reliever at the very least to see more information relating to why an assertion failed immediately in the same sense without digging into the source file where it occurred after getting that jolting surprise.
In the same sense, if your code fails to compile, you don't want to have to go look up a specific line number of an external file containing documentation to get even a remotely human description of why the compilation failed. It's far more relaxing to know the issue sooner and get at least a little bit more information about why this unanticipated failure occurred as quickly as possible since it'll leave you in a pretty foul mood otherwise. Imagine if compilation errors showed you a hex dump followed by a citation of a specific line number of an external document file through which you can look up the cause of the error.
For fail messages, I'd say the most soothing information is often contextual information giving you a good clue as to where the failure occurred (from a high-level standpoint that doesn't require looking at a specified line number of a specified source file) and not merely why it occurred, since that's typically the first gut reaction when encountering an annoying assertion failure ("Where the hell did that happen?" which can sometimes be an even more immediate concern than why it happened).