No it isn't. A Win32 application running over wine involves more context switching and memory contention due to wineserver and other libraries eating up resources.
It is the wineserver that handles all accesses to the registry. For that reason and many others, there is no way you're going to start a Wine or WineLib process without it. So it really makes no difference either way.
Once compiled there is no more difference between a WineLib process and a Wine one than between an a.out process and an elf one. Probably even less since in both cases you have all the PE structures (since some applications access them directly), only in the Windows executable file the PE-stuff is all alone, while in the WineLib case there's an extra ELF wrapper.
In theory a natively compiled Win32 exe might be more optimal if MSVC ran more efficiently than gcc / clang but these days that's unlikely.
Another point for just running the regular Windows executable.
So the rest of the Wine runtime is superfluous bloat. Compiling and linking against winelib saves space on disk because the code that is unused will not be linked into the executable.
WineLib is not something distinct from Wine. Rather it's just the source-level compatibility aspects of Wine: are the functions definitions in the right C header files, do they use the right types, can we produce PE executables, etc. WineLib does not have its own libraries: it uses the Wine dlls. So if you package your application with a self-contained Wine environment you can of course pick and choose which Wine dlls you want to package it with. That requires a non trivial amount of work though and it's not going to impact performance, just disk usage which nobody care much about these days. The latter is particularly true for games since they are typically multi-GB beasts these days while a full Wine is under 0.15GB.
It also means the game can ship only things that it needs to work and can tested to within an inch of its life against those things instead of some random Wine on someone's machine.
The things you care about for games are the X and OpenGL libraries, and graphics driver (including the Linux kernel part) and you cannot package those with your game. Also, as stated before there's no difference between Wine and WineLib there.
Thirdly, a game running on Linux might have to disable or modify its copy protection, change or remove certain texts and assets, interact with Linux in certain ways (e.g. disable screensaver, input devices), interact with other software such as Steam on Linux, or use different file paths.
True. The ISV would typically do that by modifying the source code and producing a Linux-specific Windows binary thus side-stepping all of the toolchain changes. He would then package the resulting Windows executable with Wine as stated before (or have someone like CodeWeavers package with CrossOver). In some extreme cases he may end up developing a Wine dll (i.e. a WineLib dll as all Wine dlls) to interface in some way with Linux and use the API provided by that dll in his game. That's pretty rare though.
Yes you could run a game on Linux through Wine and that's the fallback situation you'd still be running the Windows game. You wouldn't even register as a Linux user on some spreadsheet of the company that produced it.
You're mixing up buying the standard Windows game and running it through Wine with no involvement on the part of the game studio, and buying a Linux or Mac game that has been ported using Wine rather than WineLib. Of course in the first case the game studio is not going to know you're running their game in Linux or Mac since, as far as they know, it only runs on Windows. But if they made a port with Wine it's up to them to decide whether they track the Linux and Mac versions separately from the Windows one. If they have separate SKUs for each platform tracking is trivial. If they decide that when you buy the game you can run it on any platform then it means they'll need some code in the game to gather statistics.