Blame Digital Research!

CP/M 2.2 used forward slash for command-line options, and MS-DOS 1.0 was highly focused on compatibility with CP/M 2.2's API. It was actually EASIER to port a CP/M 2.2 program to MS-DOS than it was to DR's CP/M-86. Most of those ported programs did their command-line parsing themselves and wouldn't tolerate '/' being part of a filename.

When MS-DOS 2.0 came along and gave us sub-directories, Microsoft needed something for a directory separator, and '/' just wasn't available.

until Linux comes up with a working device driver API.

Somebody who wants to sell a piece of hardware that works with Windows merely has to build a single binary image that will work with all builds of a major Windows version. One driver binary for all builds of Windows 10, for example.

Linux's unstable driver API, kernel-version-dependent symbols and run-time late linking means that the only viable path for a hardware device driver is for it to be adopted/maintained by the kernel team (or a distro maintainer) and built/distributed as part of a kernel release.

Otherwise, the poor guy trying to sell hardware either has to build the driver for every single kernel release/variant, or expect the user to compile the driver on their system. Neither path is viable.

Getting your driver accepted by the kernel team is a chicken/egg problem: The Kernel team is unlikely to bother with it unless your hardware is widely used under Linux, wide use is unlikely without a driver.

Linux will never be a viable desktop operating system until it has a stable device driver API comparable to what Microsoft provides for the Windows kernel.