just look at /lib/firmware for folks wondering what this is about.
These are my opinions and in reality there is no real answer it is all opinions, you would have to poll the teams at each of these vendors and you may find a different answer for each one. There is no rule here.
Yes you save on flash, flash costs money and if you can save on that better for you, sure you trade that for ram, but I think that is a fair trade cost wise.
Second you dont have to do field upgrades, you dont have to have the user download a firmware update and possibly brick the product. Ideally your firmware should be good enough at product release to never need a field upgrade, but we are in a post microsoft, reboot/reset and see if that fixes it world. So the firmware can both be specific to the operating system as it is tied to the driver for that operating system and second if/when the software updates on the operating system happen the firmware for the embedded devices can get a free ride.
In some cases it is just the product these products use a popular usb microcontroller for example that has for whatever reason become commonly used in a product line, or a product vendor does the devil you know vs the devil you dont and sticks with this solution.
With the IoT devices I doubt they have bulletproof firmware on product release and new hacks will come along to attack the IoT firmware for a product line so having a quick and easy way to update without bricking is desirable, granted having a file on a computer hard drive is another thing to attack to gain access to a network. So there are pros and cons from a security perspective.
as far as generic driver you have to look at the os and the product and how it enumerates, etc. If my keyboard and wifi dongle used the same part how would a generic driver know them apart? If a product family or enough devices somehow adopt a common enumeration/firmware load/reenumeration you could but dont have to write one driver to cover the firmware load. really is an implementation thing, thus operating system and version specific.
One of many drawbacks here is that you may have to write a loader for each operating system you support where if the firmware was in flash on the product you might not have to, depends on the product and the protocol to the host, etc. Likewise the firmware download protocol, etc. Even if a generic driver was used to do the firmware download you have to put extra work in providing an operating specific software package and installer to put the firmware in the location where that operating system and driver expect with whatever control files or registry entries that go along with it, where if the product had firmware in flash that is less you have to do for the product to work. It also just works the first time they plug it in rather than do a two step (there is a reason why some products you buy strongly say do not plug in until you install the driver, this is one reason, they want the firmware ready before the peripheral wants it once plugged in the first time).
there is no right answer it is personal design decisions, you trade work on one side for work on another. You can potentially save pennies to dollars on the product cost itself trading those for "bits" the user pays to store on their hard drive. So long as you dont trade that for tech support bills because you didnt get the overall system design right.