Fixing the issue has been possible and should have been done sooner much much of the sooner.

It requires restructuring of their database and how it is accessed, and the longer one waits to do this the more difficult it becomes to do. This is applicable in all forms of software development and welp kinda anything really.

It is like waiting to clean until things are so very messy you no longer wish to clean. Or, building upon unstable foundation and now must lift the entire structure to rebuild its foundation.

Am I certain on this? Nope! I am not working within their database but the behavior of their system appears to corroborate my own theories.

Optimally login requests should behave like this; [client; sends and receives login credentials/character data] >< [queuing server; first point of failure also cheapest to maintain. Responsible for requesting status of caching/login server.] >< [caching server; caches login info snapshots. Only accepts client requests from queuing server when login database is overloaded. Second point of failure.] >< [account info database server; receives and sends login info auth token to client or to caching server when overloaded. Reports status to queuing server] >< [queuing server; like previous this queues requests from login server for character data once client has progressed this far.] >< [character database; sends character info down pipe to client. Final point of failure] >< [main queue; where we sit when waiting, purpose obvious.] >< [main world server; where we connect once world server has available space.]

To shorten hmm, [client] > [auth server infrastructure] > [character database] > [world server]
NOT [client] > [hacked together mega database handling login requests, character data, and also running the world server].

Once you are within queue you should never be booted further down the pipe then the previous step if queue server fails. This would require making all previous requests again further overloading their servers. You do not program this way it is stoopid for what should be reasons most obvious.

When assisting in forum development or other largish servers (50,000+ users) I encountered all of these problems. Especially when working with server emulation for mmos. There came a time where splitting auth servers away from other databases was essential, especially item lookup.

2002 not only boots you from queue it closes the client forcing you to re-login. I suspect it does this because their servers must process your login credentials each time you enter the queue and do not cache your login state. This was simplest solution for Square. I have never played mmo that closes the client on failed character data retrieval.

The condescension in comments rather then willingness to discuss this on perhaps technical level is why the problems with their infrastructure persist. For reasons unknown I seem to enjoy wasting my time here, I suppose.