It's not a hardware problem on the client side, it's a hardware problem on the server side, and a limitation of networks.
Let's get technical.
Database Query Constraints
You teleport to a zone. There are 100 characters standing around the aetheryte.
Your local client sends a message to the server with "I'm now standing at XYZ. Who is around me?"
The local zone is stored in your system; it can load the environment instantly.
For each of the 100 characters around you, it has to load their names, titles, their character appearances, all their visible gear, and any fashion accessories and minions.
Currently that data package for visual display is wrapped up in a single efficient table, so the character can be queried and all 100 appearances can be sent to you.
(Minions are generally sent via a secondary query a moment later, which is why you have all 100 minions load afterward.)
So your client is constantly sending and receiving small sips of packages from the game.
Databases have several ways of storing data: A null value, an On/Off switch (Boolean true/false), a text string with a character limit, number values, links to other tables in the database (and that can be a rabbit hole with links upon links upon links), and finally BLOBS/CLOBS (binary large objects - usually images. or character large objects - big strings of text.) In XIV, the BLOBS are linked to objects stored locally, instead of within the database itself - this is the character meshes, textures, etc.
The character object sent to your client is a mishmash of the null values, true/falses, text strings, and links to character creation values and gear set tables values, which your local client reads out as a displayed character.
Adding 1 data point for each of the characters is 100 new data points. Add 10 new data points, and its 1000. And those have to be rendered for every single character around you too, not just your character. Every time a new person zones in, the server has to run a character query and send it out to everyone else. And this is happening CONSTANTLY - not just in the place you zoned in, but EVERYWHERE on the server, every second. Data in, data out. And there are also queries that go to other tables every time you open a menu.
But hey, let's assume they now have state of the art hardware in the data center, and their databases can run those queries at the speed of light.
ISP Backbone Limitations
Every second, for the 3000-5000 active characters that the world server currently has online, there's a constant stream of queries going to and from the server and the database. That data now has to get out to the clients... over the Internet.
I suspect the reason that they have the current limited character data is because they found a comfortable raw character table size that can be loaded in a single query and sent in a single packet of data (~1460 bytes of data is the standard maximum payload on Ethernet. IPv6 can technically support more, but it's not standard at all yet.)
Adding more character points may not be "just one more table column, bro" - it could be DOUBLE the packets needed to load all the characters in a given zone because it's now exceeding the maximum payload size of the packet itself.
The time may have come to accept that, though. Double the packets per character, double the character data. Most ISPs can probably handle it. And just add another second of dark screen loading time when zoning in for the second batch of character packets to load.