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:
- 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.
- 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.
- Regulations compliance?
A lot of radio-related firmwares (wifi, cell, bluetooth) enforce the compliance with the frequency spectrum regulations.
- 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.