In principle, whenever you see a game marked as "Linux" on GOG, it will be a code compiled for Linux ( and note that on GOG it means "for Ubuntu, its derivatives and relatives"). Of course, this includes DOS games that work with the linux version of an emulator (Dosbox, ScummVM) . But no Wine used on these

Wine will allow you to try the other games. Some with success, some with trouble. Wine is actually configuring a windows virtual space in which your windows code will be executed. If you have a win7 install , it's indeed a matter of preference. But if you run a pure linux install, it's damn useful.

well for new games they are most native port (no wine), but for older games wine is a really good tool and since it is only a compatibility layer (not an emulator, liike the name say) the performance are really close to native (and if we look at old games there is really no difference).
to know if a game is a native port or just a wine wrapper you just need to know that a wine wrapper contain an exe and a drive c folder, just like a windows machine.
If you only use windows there is still a reason to consider wine... since Linux is free and you can create a wine wrapper with a specific wine version, some old game (that may not work on windows) may work on wine.
And there are many tools like PlayOnLinux/Mac, CrossOver and, for mac, site like portingteam and apps like portingkit, where you can find many premade wine wrappers so that you don't even need to know how to configure wine for a specific game (you can still usually find every information you need on winehq).

Make a wine wrapper also mean that you create a "isolated machine" where you only execute your game.

I think wine is a really good tools for older game but it's usually better to avoid wine for new game.

Mostly true, but not completely. There are a few games marked as supporting Linux that are really a 'Wine bottle'. e.g.: the FlatOut's, Enclave, Two Worlds, and a couple of others.

Hi! I am 100% linux, and to think "wine" is "not pure linux" is wrong, in the sense that only function calls are not direct.

Technically "wine" = winelib is a "free implementation of WinAPI". Its a library, implementing official winapi - a call translator. Its 100% native code, its just running with some translation overhead. This can not be said for example, about Dosbox, which is used at 100% (?) titles from Dos era - regardless if they run on linux, mac or windows.

The advantage of having native release just means that this translation overhead is removed. The impact of overhead varies, usually its 1-5% - but get imperfect opengl implementation or low performance opengl calls, it can impact fps pretty deep. This is why, of course, having Linux release is very good, but its actually not critical.

Reality is that before Steam, linux (regardless of how awesome it is or was) was not pre-shipped for free in stores and did no under-the-table oem contracts; thus the marketshare was low, thus nobody cared to release, thus hardware makers typically assigned lower priority to it.

Marketshare is everything in commercial segment. But it has nothing to do with internal qualities of the system.

What this means in practice - if the game runs at silver or higher level as specified at "wine appdb", you are fine with windows-only release. If game uses dosbox - you are fine with windows-only release. If the game is provided for linux - you are also fine.

Some games looks more blurring under wine (with default configuration).
I guess wine genies could adjust settings to make them pixel precise, but I do not want to research that.

I do prefer Linux native port, but I am OK with games that only run on Linux via Wine.