This is only true if your engine is abstracting nothing away and there wasn't any common denominator in APIs across systems.
Given that neither is the case for popular game engines, the statement is wrong. You also don't have to test gameplay related things on both systems, only technical aspects, and only a small subset of them.
The current reality is that it really does increase the testing surface area by a substantial amount. Even if it's only +10-20%, the addressable market on Linux is nowhere near that size, so it is really difficult to make a good business case for supporting Linux natively. Large studios could certainly do it, though it'd basically be getting "subsidized" by other target platforms; small studios though, not so much, the math just simply doesn't make sense currently.
The engine abstractions only do so much for you - at the end of the day, it's another thing you have to test and provide support for, with the latter being the most troublesome and resource-intensive, in my experience.
Where it rapidly can get dicey is optimizations related to rendering, and that's also commonly a massive "unknown" up-front. This includes "GPU" optimization itself (ie shading) and also optimizing for CPU=>GPU pipeline/bandwidth -- both of which are difficult to abstract and/or the abstractions that exist tend to leak a lot.
The latter is the area where I've personally experienced the most pain and those situations are often full of unknowns & full days of developer time spent working on/debugging platform-specific issues from an actual Linux test machine. Having to devote full days of developer time to Linux-specific GPU-related debugging is painful -- specifically because it rarely generalizes or improves experience on other platforms. For a small/indie team, it's extremely expensive because of the big "unknowns" that exist (ie lack of familiarity & uncertainty of outcome, etc), and especially because of the opportunity cost/the time spent is likely to benefit <2% of customers, at best, which is a very difficult pill to swallow unless you've got a really big pie to begin with!
I'll end the same way that I began: Proton very good, great even! =D
The most high profile case I recall is Rust, but there've been others
There is no ABI stability, except linux kernel syscalls and the alsa-lib (for how long?), on glibc/linux based OS.
And we are talking really short time frames. For instance with glibc gnu symbol versioning, game binaries compiled on a recent glibc will break all distros older than 1 year and a half. Game devs must be careful to compile against a VERY old glibc (like a decade?), what a pain. It is not that dark: cross-platform 3D engine devs are aware about this and are carefull about this (usually).
Game binaries are also destroyed by the accutely toxic c++/libgcc_s ABIs (did happen again very recently). Hopefully, compilers have -static-libgcc and -static-libstdc++ options, but it does solve only partially the issue. Many games are using c++ (I have an extremely negative opinion about this language), and the static libstdc++ is not libdl-ing any of its dependencies from the system, then those dependencies end up in the static loading list of the ELF binaries... often with nasty gnu symbol versions. To fix properly this, it would require a fork of gcc(clang?) static libstdc++ which does have a libdl mode, namely does libdl everything from the system.
To say the least, the main culprits are... gcc and glibc devs (IBM? MIT?). It is so accute, I started to think conspiracy: microsoft pulling the strings in the shadows, or those devs trying to blackmail valve/game studios with planned obsolescence (are laws already setup against this type of accutely toxic scam?).
Since the game binaries should libdl everything from the system, they must be simple and pure ELF64 binaries. Namely, using a minimal set of relocation types, no c/c++ main(), and have to manage system TLS variables (for instance errno) with the sysv ABI __tls_get_addr() (this may require a bit of ELF header parsing... if there is an clean ABI way to reach the ones from the libdl-ed ones).
Game binaries would statically load only libdl (not even libc) to dynamically load the video game core libs: xcb libs, libxkbcommon(wayland/x11), wayland code is static into the binaries, libasound (pulseaudio/pipewire/jack/etc are hidden behind the alsa-lib API), libgl, vulkan, and even the libc if requiring anything from it (name resolution?).
About 3D programing, vulkan would have to be used very conservatively, nothing fancy.
proton is a massive amount of literaly and fairly, garbage, software, microsoft grade. It is a money sink hole for valve, not to mention if I recall properly, it does include straight copies of closed source windoz components, that to make things even worse. I manage to build a lean wine win64/vulkan/dx12->vulkan(at least avoid that thing which is dxvk) with a C compiler, but I know that nearly no doz game will content themselve from that to actually run.