in your example did windows have this by default no, took time for drivers to appear but no guarantee they worked on next release, with Linux, once you have them, they generally work across releases. IT's all about changing the attitude of users and developers to truly support and change Linux in to what we want it to be, secure, easy to use, Windows compatible until native apps available, fast, light weight, and the core os fully open source, drivers can be propriety without breaking all this. It may be a pipedream, but I think if enough heads come together it is doable now, especially if like the UK/EU of users are forced to switch away from Microsoft in government.
For windows, when it comes to driver support, microsoft has done a lot of work in that area since windows update will automatically download and install a wide range of 3rd party drivers, though often it will be older driver, thus requiring the user to still download the latest drivers, but it is likely to get things working.
For windows, while they have horrible released like windows 11 (horrible taskbar that takes up too much vertical screen space). The design culture of windows, focuses more heavily on automation, thus if a piece of hardware does not work properly or is not supported on a newer version of the OS, then the design culture meant that an automated solution was more likely. For example, getting an ancient Audigy and x-fi soundcards (meaning going beyond basic output and restoring its EAX features) working in windows 11 was reduced to a process of downloading an exe, double clicking it, and then clicking next a few times. While the developer of the modified drivers could have made it into a long winded CLI process, but since the super majority expect a GUI install process, that is what is offered.
And in the rare occasion where something is a CLI process, often a batch file will be included, and if not, one will be created be someone else.
For example, when you get lucky on XDA developers and you want to install a different ROM on your smartphone, but keep your current modem files (useful in cases where some device makers will release a new android version on the EU, but discontinue support before the US model gets an update. Often you will see guides where they are long winded with many steps, followed by users complaining that they made a mistake and bricked their device. Then it goes away when someone comes back with a simply batch package to automate everything.
On the linux side of things, it is rare to reach that stage when a project is at the stage of a random package linked on the forums, and since CLI steps often do not work perfectly on different versions, it is not novice friendly.
For linux, developer attitudes need to change, to move away from the "get gud" attitude, and move more towards UX.
Users are willing to accept a different UI if it is intuitive, has features they have come to like, and they are not required to loearn a higher complxity of skils than what they needed for their previous OS. For example, if they didn't need to learn CLI in windows, then no matter how well you market linux, the novice windows users will disengage the moment they need to learn CLI in linux, especially since there are far fewer workarounds. For the novice user, in windows, when CLI comes up, often their experience will still be a double click process because someone would have either done a batch file, or made a GUI frontend.
This even applies to more niche items, for example, a lot of the SDR tools that lack a proper GUI, quickly got batch files and GUI front ends which made the process of integrating them into applications such as SDR sharp, a double click process.