Why do firmware and drivers have to be separate?

No, both types of software usually are running on a different type of machine.

Firmware is running on the processor/controller on the peripheral device, the driver is running on the CPU of your machine. Those usually even are different types.

In theory, one could task the CPU of your machine to do all the bit-banging in the peripheral device. This has been done in early computers. But this comes at a high price.

Often, external protocol involves hard timing restrictions (think network card, or a CRT display). Your CPU will need to handle a lot of interrupts to get the work done at the right moment. For that reason, on the famous Sinclair ZX-81, display went off when the CPU was doing hard work - no time for screen refresh :)

Hence, we try to uncouple the work of periphery devices nowadays. CPU will get notified when an full network packet arrived, and doesn't have to poll a wire for changing bits.

Firmware runs on the device using the hardware of the device directly. One way to look at it, is the firmware is an API for the OS, it does not matter what OS the computer runs, if it receives x instruction, then the firmware will do y, and may return a value z. The device will have it own clock that will control the speed instructions are preformed, its own memory, and the processor on the device can be different then the computer, eg the computer may be an amd64, but the device has an arm64 processor. Firmware does not communicate with the CPU or ram directly, it takes instructions from the bus, and puts data back on the bus.

Drivers run on the Computer either at the OS kernel level, or the OS user level, a driver is OS dependent, and must meet the requirements of the OS to be able to function. A driver will generally handle any work that needs the CPU and or the RAM of the Computer, once the per-processing of the instruction has been completed, the instruction is passed to the device via the firmware.

In fact, they don't have to be separated.

In a lot of cases one can walk over the whole spectrum from controlling the hardware directly from the central CPU all the way to implementing as much as possible in the firmware.

Here is an incomplete list of design considerations about firmware/driver balance:

1. Do you want to use a standard driver or interface?

Of course, one can create an USB flash memory stick that exposes the NAND semantics to the driver and save the controller chip. And distribute your exotic the driver somehow (for Windows, Linux, MAC, Konica printers, etc, etc...) . On the other hand, users and OS developers alike expect the USB stick to work with the standard block device driver. Optical mouse with non-HID interface? Not really a good idea either.

2. Is some of your functionality patent/NDA/trade secret burdened?

The driver (even if compiled) is available for easy reverse-engineering and altering, the firmware - much less so. This is quite often the case with video chips.

3. Regulations compliance?

A lot of radio-related firmwares (wifi, cell, bluetooth) enforce the compliance with the frequency spectrum regulations.

4. Cost? There is usually an optimal point in regard to both design and manufacture expenses.

etc, etc...

On the top of this, there are quite a few devices that lack ROM memory so the firmware is actually a part of the driver and is uploaded to the device at every power-on.