Additionally, errors from the backend can be overly-technical. While an over-simplified error message isn’t helpful, an error message that says something like “Unable to query ATL_PROFILEMSSQL_05: table ‘demographics’ does not exist” is equally unhelpful and feels more like the user caught you with your pants down. On the frontend, it can be a bit terrifying to display whatever message comes back from the backend, so you either create your own simple “user-friendly” error message (“Unable to load your information!”) or create some sort of map to match server messages with user-friendly messages. The latter is dirty and nearly impossible to maintain if your backend is changing a lot.
On the flip side, backend devs rarely consider themselves to be responsible for UX and just want to provide error messages that correctly reflect the situation (like the fact that your profile database in Atlanta doesn’t have table ‘demographics’).
A system that correctly translates a technical issue into an actionable user-friendly message is a large undertaking for a major product. You need a combination of internal detailed error message logging, friendly user-facing error messages for each situation, and if you support multiple languages, that creates another layer. Robust error handling can quickly turn into a major project with serious UX-related decisions, and you definitely need someone to take responsibility. Otherwise, most frontend and backend teams are just going to play it safe and avoid compromising their own goals.