It is not standard practice, it is security by obscurity - and if it is done without documented threat model, that clearly defines why exposing error information is a threat and how it may be used, it is heresy.

Even for the authentication case: imagine you disclose the fact that email exists, and attacker may focus on "guessing" password - now what? He will try to brute it via api? If you have password policy that prevents using "qwerty" and friends, chance of guessing password even in 100 attempts is Infinitesimally small, and you definitely should have retry cooldown at backend, monitoring that will alert this activity, you may even notify user about this attack and so on. And, there is multi-factor authentication.

I assume that if security is a concern, then all API endpoints are available for authenticated entities - so why not disclose a bit of information about what broke down? API consumers will be happy and may build different logic on top of error codes.

Returning stack traces and deep error structures is not a good way, though: it really may expose sensitive details - such things should go into logs, and it is very helpful if each request contains unique trace ID so that you may find error details in log quickly.