As far as sound goes... Linux has a very wide range of options available to it.
Keyboards are standard... controllers might be an issue.
And WINE is an emulator... not a platform. It would probably work in WINE as is. What we want is a full fledge PORT to Linux.
But who is going to pay for that Linux version? Where is the economics of spending the time to write it, and then to maintain it?
Look at how many clients they have already,
PC
MAC
XBOX One
PS4
And No, WINE is NOT an Emulator.
But you are totally missing the point about the API's. It is the stuff programs uses to talk to hardware and system. Because you will not write your own USB protcol driver to talk to a Keybaord you rely on the OS to do that for you. So they do. And still you do not write your own listening code to talk directly to your keyboard, the operating system does that too, so it decodes the data arriving from your keyboard and let your program and others get the refined version of the data. Ontop of this, we usually get some other API's that are used by games, on Windows we have DirectInput as one option, there other options to use as well.
The same story goes for Sound, multiple layers of software before you program can use it.
Controllers, the same
Graphics, we have two standards, DirextX, and OpenGL/Vulkan.
Now examine these two and where can play Elite today.
Windows:
DirectX (uses)
Vulcan
XBOX One :
DirectX (uses)
PS4:
PS4 specific API (problably uses)
Vulcan, but not from the start
OSX:
OpenGL, but lacks certain functions, so no Horizon (uses)
And for comparison
Linux:
Vulkan
OpenGL
So they most likely are using 3 API's: DirectX, PS4 native and a limited OpenGL implementation
So now you want to add 4th API, Vulcan or full OpenGL. And rewriting any existing client to use Vulcan/OpenGL would require even more work, and the only benefit they could get from that is possibly removal of the PS4 native API.
Now, onto the Vulcan/DirectX 12 issues. These APIs are simpler than they predecesors, ie OpenGL and DirextX 11, as they do not contain as mush calls to alot of stuff, this is because many thinks that they can write better code to things that you need specifically for you game, and not have to implement support other uses for that function. And this should give us more performance, And yet when comparing performance between OpenGL/Vulcan or DirextX 11/12 they are about the same. And most of this is because the OpenGL and DirectX 11 was pretty optimized to begin with, so it takes alot of skills to optimize this by yourself, and even if you can write more optimized version than what OpenGL and DirectX 11 had, is the rest your code as optimized? probably not, as you are not writing that code... So bad coding practices is in most cases having ALOT more impact on performance than choosing between OpenGL/DirectX 11 or Vulcan/DirectX 12.
So it is bit more complicated
But why do you want a full fledged port in the first place? What do you think you would gain from that as compared to a working Wine version?
If you say better performance, then most of the time that is not true. Have a look at Phoronix site, they have done some great work at comparing performance between Linux and Windows and Windows client running on Linux using Wine. And the normal outcome is that native Linux client is generally the same the Windows client either on Windows or on Linux using Wine! and the only times I have seen a huge difference is when FPS goes crazy high, over 170 FPS. But then what effective difference does this make in the real world? do you have a monitor that show 170+ FPS?
Another interesting find Phoronix did, was that the use of older DirectX versions in Wine or older OpenGL versions where noticeably slower by running the Windows version in Wine. But this does not current games. but an interesting side note.
And I have seen atleast one game that did have native Linux support to scrap that client in support of actually running the Windows client via Wine, as that was actually faster and new fixes, patches etc always came to the Windows clients first and later to the Linux client. Now the Linux crowd got the same updates as the Windwos crowd, and it was tested and verified to run via Wine.
So from a business perspective, I think it would be more efficient to actually take the time to adapt the Windows versions to run via Wine on Linux than to write a "whole" new client. And after the initial learning curve for the limitations of Wine etc, any further maintenance would be more cost effective, as they are only maintaining one client, that runs on two platforms. And testing done from Phoronix suggests that there should not be any performance hit by doing it this way.
And I have totally avoided the dark pit of DRM and why that crap is in most cases totally incompatible with running stuff on Linux... and sadly DRM hurts the honest players on all platforms.