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.
At the same time though, building a game that is easy to port is good engineering in the first place. Even if you only release on mainstream platforms, writing platform-agnostic code can save you so many headaches down the line when you want to release on console/mobile etc.
You're not wrong and I generally agree. In my experience, the issue that comes into play most often is performance optimization. Usually "generic" optimization (read: CPU side) is fine and testing the game on other target platforms (not just Linux) is often beneficial and commonly brings about changes that have positive impacts for the game across platforms.
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 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.