Polish in the strictest most original sense -as I had learned of it about 15 years ago when I started 3D modeling- is a term that comes from the realm 3D modeling and world building. It refers to the level of physical interactability of objects placed within a 3d environment (primarily interactability between an avatar/character within that environment and the objects inhabiting it).
Gamers have gotten a hold of this terminology within recent years and have expanded it to possibly refer to a great many things. To the extent that it has lost a lot of it's potency as a word. This understandable. Your average player will never see game barriers and bounding boxes as a physical thing. But, when i use it, it is in the most basic meaning, strictest sense stated above.
[that is the short answer, the long one involves understanding a little bit about how a game is built on the physicality level and understanding this is a gateway drug to becoming an avid modeler addicted to making games or components for them...which in my case has turned out to be a nice way to fund my gaming costs without dipping into my actual income...if your not the deeply inquizative type and only want the jist of it you need read no further...you have been warned :p ].
So lets look at what polish actually applies to more closely.
3D models, or concisely mesh, have a physical constraints. This is most typically defined by the mesh's outer most limits. Players in an MMO do not see these outer limits of objects. But, can tell they are there and often refer to them as Invisible barriers, Invisible Walls, Game Barriers, Map Barriers, Kill Lines etc...They are and in most instances what intended. Here is a visual on a typical bounding box around a simple shaded mesh that shows how Modelers and environments choose to draw them by default typically (using the objects outer most limits to define a right angle box - the green lines aside from the Y axis line is the bounding box)....
This is why a player may see a ledge that it looks it can be jumped onto. But, when they attempt it often slip right off. Modelers can change this where needed. A modeler can change the scale of a bounding box and it's position...Like so.
[BTW If you want this sub-division modeler it is a great one to start out on and you can find it here.]
With a method like this a player can jump up on said ledge. But, the issue in doing this is two fold. Firstly bounding boxes exist in the first place to define in simple easy terms where an object begins and ends physically. an object may appear visually outside of a bounding box, but only has assignable properties as being something that exists interactably, for the parts of it that are within the bounding box. This is because all machinisms involved need to be able to understand where one thing ends and another begins. So, while a player could now hop up on our ledge they will fall through the wall above it.
The second part of the issue is that bounding boxes are typically not conformative to the shape of an object and for simplicities sake cannot be made so. If the developers want a player to be able to jump onto a ledge like this on and not fall through it requires making a second barrier (often invisible) or having the structure itself be made of multiple objects. The more they mess with this the more likely a mistake will be made that will allow for game exploitation through map breaking. So in general unless truly nescessary developers tend to let the larger more simplistic shape serve as the bounding box.
Modelers, Programmers, and Sub-division/rendering software developers alike have been trying for years to over come this issue. And, they have had limited success. Mesh made in formats such as colladea ( .dea) don't need bounding boxes persay (rather they don't need one assigned). They rely by defualt on their own true shape (more or less) to define where their boundries are, and can be given other physical shapes after the fact.
The issue (of course there is one) is that this takes a resource cost at least equal to the mesh itself (the reason why bounding boxes were simple to begin with... in order to avoid just that).
So, a game that would have mostly objects with conformative bounding boxes defined by the shape of the objects themselves would effectively be twice as resource heavy as a game that simply found clever ways to use regular bounding boxes. There is the comprimise of giving a mesh a physical shape that roughly fits it's true shape but it a little less detailed. Not as complex as allowing it to simply use its own shape, and not as restrictive as using a regular bounding box...but the affective...weight of the object goes up none the less.
The less area a bounding box or physical shape covers on an object the less resources the objects physics cost us (this is often format subjective though). But also the easier it is to slip into many situations because bounding boxes can be fickle. They often like to combine with the outer limits of objects that are linked to them to make entirely new bounding boxes that the designer did not pre-define (by the environment choosing to use the outer limits of both linked objects as the constraint for the linksets physical shape over letting it be decided by what was designated for it). So, a bounding box should only be as large as it's purposes need it to be.
Lets extrude our model from before into a simplistic line of fence and have a deeper look at this (for my own piece of mind it will be mortised tenon on pegged posts with a simple slightly weathered wood texture).
[Worth mentioning is this small application called wood work shop that you can find here. It is completely free and gives you the ability to make just about any wood texture you need. (the company who makes it has a few other pay for softwares, but this one in specific does not pressure you to buy them and is not on some sort of trial version)]
So in the above image you can see by this bounding box (the bright green lines) that it is intended to act as an initial obstruction, that a character would likely be able to jump over walk around or walk on top of. Given the height of a a fence in relation to standard character height though your character would have to be a gnome or hobbit or something like that, to go under the fence).
This the kind of physical shape that may be given to an object that is intended to be used by...say for instance, a ranger fighting melee monsters. The NPC monster is likely too stupid to get around the fence so the ranger can stand on the other side a little way back and hit the monster while not taking damage (a good deal of more modern MMO's don't like the idea of ranging classes not taking damage and have monsters reset HP and loose agro -returning to their normal range zones - if they are not able to retaliate after so many seconds).
If this fence is linked to another exact same kind, the bounding boxes will combine but only to the extent that they were previously, each defined.
Now, if we wanted this fence to run along the edge of a mapped area to show the point at which a player can physically go no further we would simple make the bounding box exeptionally large (and sometimes unreasonably large). like so...
A bounding box this large means a player could likely stand on something half their height (like barrels or crates) and still not be able to jump over it. it also means a fence line can have small gaps and be unlinked, as long as two bounding boxes themselves have less than a characters width between them...that player who despreately wants to get out of the map isn't squeezing between them either in this case. The bounding box, also being twice the thickness of the fence means the player is highly unlikely to movement glitch their way through the box itself....
This is a "You go no further." kind of bounding box often placed half way up mountain slopes (that by their steepness alone usually wouldn't allow you to go up and over given game physics, but this is an extra measure...just in case you were to find a spot not so steep where climbing up and over would be pheasable otherwise) and at any other map barrier like a cliff or narrowing passage into a loading zone or screen.
Another aspect of polishing is when they give an object no bounding box at all or set it to non physical. this makes the object a thing that visually exists but can be passed right through by something like a character. This is often applies (as a good for instance) to tie down ropes on tents in campsites. Also roofs of many buildings, and islands in the sky that you are never intended to be able to get to. If they can get away with giving it no physics, it's all the better. less physics active uncesarily means less resources cost for the game.
When developers give this aspect of a game a lot of focus and thought, employing what ever tactics make the most sense for the situation. And are over all very miticulous in how they do this to where most things make sense in the way a player can move about in the game environment...
This can be considered a Well Polished Game. However...
When developers largely ignore this aspect or rush through paying more attention to it due to in-game exploits, a game tends to end up being poorly polished or over polished. This is where a character can get stuck on objects in the environment easily, and even have difficulty going some where they should be able to go. Also the small frustration of being able to jump but not get ontop of a rock that that should be able to get on top of is a side effect.
This termonology and alot of others like flashing/ z-buffering were encountered by gamers in Social MMO's with a high degree of player made content . Like the oldest true social MMO Still running called Active Worlds (started in 1995 and to date it is still open though it should probably change it's name to not-so-active worlds for very apparent reasons, if you decide to take a look at it). Or one of the newer more popular ones called Second Life (a.k.a the WoW of social MMO's).
People who wanted to play and explore in these MMO's (perhaps sick of the gaming grind). And, maybe build things the way they wished them to be, to some extent, were through these Social MMO's put in direct contact with the people who knew how to do everything game developers do wanted to apply it in far more creative ways.
This (and especially in the past 7-8 years) has exposed gamers to the usage of termonology that doesn't describe direct gameplay efficiently without a deeper understanding of how games are made. So, things like 'Polish' have become very watered down words.
Sometimes people are talking about terrain.
"the map is not very polished."
Terrain Is usually made by starting with a flat panel (a quad plane) and building it or sinking it in places to create the desired topology, Like so.
[And hey many programs like this one are so simple it takes all of about 5-10 minutes to pretty much get how to do everything. You can this one here.]
This is done in map blocks or sections. Where two sections meet there can often be alignment issues if the creator is not careful. Which basically can create litteral gaps, holes, and apparent tares in the map. I think this is a fair and applicable extension of what polish can mean.
As is z-buffering of flashing showing a lack of polish (alignment)... and this is when two surfaces try to exist in the exact same place and constantly fight each other for dominance based on player position and view in relation to them. Because this still has to do with an issue of modeling well and positioning things correctly. I can see this as another fair extension of the term and it's meaning.
It is when we start using it to refer to graphical level of detail, user interface, and quality of graphics...that we start to loose the meaning of the word. The reason is these things are more often then not, changeable by the player. Different players, with different machines and connections will experience the UI (user interface) and LoD (Level of detail) in different ways. So, taking a term that is meant to factually refer to something concrete (the physical properties and alignment of models). and Applying it to something so subjective, ruins it the termonology.