You seem to miss the point. High poly count does not automatically mean to have a bad artist. When that would be the case then you would label all current top game artists as bad artists since the current games generation uses a very high poly count for its characters, compared to the usual 5k to 10k characters that you can buy at turbosquid or similar places.
When you need closeups then your geometry better does not look too blocky. And a terrain mesh (not a heightmap terrain) is such a case where you quickly run into the blocky look with just 65k tris.
Sure, i can create a level or a character also with 1000 triangles. But the best artist cannot make it as good looking as a 50k level or character. Detail can be done with techniques like normalmapping to some extend. But the best detail at a mesh comes from geometry. Guess what stuff like micro tesselation is good for.
What makes a good artist is to use as much polygons as needed, and as few as possible, given the limits of the current project. This could mean to have the almighty 1000 tris character, but this could also mean to have a character with 100 k tris or even more.
Graphics area evolves still heavily. Not long ago we had just 256 colours for the whole image stuff in a game. 8 Bit. Then we had 65k colours. 16 Bit. Then 16 million colours. 24 bit. Nowadays we are at 32 bit per colour channel. And 64 bit per channel is at the horizon. Nowadays PBR is the new holy grail, and so on.
Same goes for mesh size. Not long ago 1k tris was high poly for games. Then it was 5k, then 10k. Now we are at 50k … . Same goes for texture size. There were times when you have put all graphics of a game at a single 1024x256 chipset. Nowadays you use a 4096 texture for just a face of a character …
Would you use a game engine that uses 8 bit, means 256 colours, nowadays? Would you play a game like Assassins creeds or Witcher 3 with a character made of 1000 tris? I highly doubt so 
We have the same limit dilemma for the meshes with the lightmaps in Unity too. The size is capped at 2048 since years. But using a 4096 lightmap runs just fine, there’s a extension for that around. And the bigger size makes simply more sense in some situations, like for the shadows of the trees at a landscape. The heightmap size is also capped when i remember correct.
Unity should deliver freedom, not limitations. It’s the artists decision where to set the limits. Better said, the target platform and your current project decides that for you. A game with a dozen 50k characters onscreen will most likely lag a bit when you try to play that game at a mobile phone. But might just work fine at a PC. It’s all about the target platform and how many polygons just works. And as told before, polycount isn’t the bottle neck anymore.
You can find an interesting read about poly count here. It’s a bit aged nowadays. But nevertheless interesting: http://www.rsart.co.uk/2007/08/27/yes-but-how-many-polygons/
For example, 8 years ago, Lost Planet. :
Bad artists?
Indeed. And what do you do with a level mesh (notice that i do not mean a heightmap based terrain here) that has over 65k vertices, and where i simply don’t need chunks for performance reasons? It gets split, and that means to have gaps. There is just no way around the floating point errors when you have several independant meshparts. And this results into visible gaps where the light shines through and the antialias fails.
Of course there are workarounds. The usual workaround is to extend the areas around the gaps, to extrude faces out of the involved edges, and bend them a bit backwards so that you have a X kind overlapping at the cutting edge. But that shouldn’t be necessary at all. It’s extra work. And it’s a workaround, not the solution.
Heck, even regular games got their own version of “chunks” that you have to deal with, one famous type you might know about is called octree’s…