I published my first Steam game on Linux as well as Windows and MacOS, but I don't think I'll do it again because for a single person developer (as indie as it gets) the time spent supporting Linux doesn't pay off. Within days of publishing my game I had support request emails that said "so I'm on this specific Red Hat version, with this oddball graphics driver and three monitors and full-screen doesn't work with your game properly". As I only officially supported Ubuntu I couldn't really help each exotic (to me) setup that came into my email inbox, and there was more than a few. Which I still think is a shame.
But that was five years ago. I'm pretty sure Photon supports my Windows builds on Linux better than I was ever able to do with the native executables, and at least there's that.
If you are being overwhelmed by bug reports from Linux users the Solution is to let those users triage, categorize and maybe even fix issues amongst themselves by having a publicly acessible tracker. Just like with forums for your game, you might even find people that will moderate those bug trackers for you. Valve realized this early in the Steam for Linux beta and have been using GitHub issues [0] for all of their Linux ports.
As for the differences between Linux distributions, I think the concerns are greatly overblown. The biggest difference between Desktop Linux distributions boils down in the versions of various libraries that they ship. For most of those you don't need to care at all and should ship your own version (or use the Steam Linux Runtime [1]). Base system libraries (glibc, OpenGL, Vulkan, audio) that you can't ship (because they contain hardware specific code that needs to get updates even after your game is EOL, or for other reasons) tend to provide strong backwards compatibility so you only need to target an old enough version to cover all the Linux distributions you want to support. A complicated one is the C++ standard library since some graphics drivers will depend on that - I recomment statically linkingyour own version and not exporting/importing any C++ symbols in your program.
I agree with others here that it is fine to only guarantee support for a limited set of Linux distributions (e.g. current Ubuntu LTS). However you should not consider reports from other distributions as a nuisance but rather as an early warning system or "linter" that will let you know about potential problems that users on your supported distribution (or even your users on other operating systems) may encounter in the future.
Next you can have various windowing systems, window managers and audio systems (even on one Distribution). Just ignore those: Don't interface directly with Xlib or pulseaudio but instead use a proven abstraction that takes care of the different quirks for you: SDL. That is, assuming you are not already using an engine with mature Linux support. Even if there is a quirk not handled in SDL, your users now are empowered to debug SDL themselves and fix the issue there, benefitting everyone. SDL will also make it easier to support future systems: if you never talk to Xlib and GLX directly, SDL can give you Wayland support for free.
Finally you have drivers. This isn't really much different than under Windows. Like with Linux distributions, issues with one driver often point towards things that just happen to work correctly in another vendor's driver but could break in the future. Having testing on more drivers is a good thing. Compared to Windows however, there is one big advantage: With the exception of Nvidia (and the proprietary AMD driver, but no need to care about that one) you (and savy users) have full source access to those which makes debugging some issues a lot more feasible. But further than that, they are also developed in the open with a public bug tracker [3] which gives you direct access to the developers. You can even chat with them on IRC if you like - just make sure that you are not wasting their time any more than you consider your users are wasting your time by reporting bugs.
I have also seen many concerns in this thread that bad reviews from Linux users will tarnish their score. First, realize that Steam reviews are always relative compared to expectations. If you manage those expectations, you can limit negative reviews - that goes for Linux users just as for anyone else. But Linux users can also help your game by recommending it to others. While the same is true for Windows users, those initial Linux users are easier to reach because there is less market saturation (especially in some genres). Using just the raw Linux sales percentage does not necessarily give you a full view of what sales you have gained by releasing a Linux port. To be fair, there will also be Linux customers that would have bought the Windows version, but either way % sales and revenue impact is not a 1:1 relation.
In conclusion, I think the main problem Windows developers face when targetting Linux are not technical issues (which there are of course) but one of cultural differences. Once you overcome those and learn how the Linux ecosystem works, you can use it to your advantage.
[0] https://github.com/ValveSoftware/steam-for-linux/issues