There may be an issue with the application, but if you tell them what ballpark the issue is in they might just work around it.

Because application errors are not one-size-fits-all. Sometimes it's because of some specific flow being broken. Sometimes it's "the site is down". Sometimes it's a "there's an error condition that needs to be bubbled up to the user". And sometimes it's a poor internet connection being mishandled.

While code fixes are not in their power to do, changing their behavior, or waiting for a better internet connection (i.e. "something went wrong" actually means "go log in to the hotel wifi") are things in their power.

>Once you have this realization, what's the advantage of showing the proper error code to the user?

Have you ever done end user support? Having a moderate amount of detail like an HTTP response code saves tons of time and headaches when a user calls in.

And some of the specific codes you mentioned (401, 403, and 429 for example) actually do give a power user actionable information. They can know that there's something wrong with their login credentials or permissions, or that they are making too many requests too quickly and need to slow down or wait to stop being rate limited. And knowing that it's some kind of 500 error lets a power user know "Ok, this probably isn't an issue on my end" which helps them stop worrying that it's something they're doing wrong or something wrong with their system.

Again, you are underestimating users. They will work around errors and can use some quite hideously broken systems to get what they need done, without any support at all sometimes. Hiding error messages just makes that a much more frustrating process. (put another way, the user probably can't fix the error occurring if they just do the exact same thing again, but they can often find another way to do what they want without triggering the error, and for this it helps to know what the error actually is)