I guess the authors of DOS didn't think a mouse was essential for a largely command line system since they probably had enterprise in mind rather than gaming.

The 1981 IBM PC was aimed at gamers/consumers, too. CGA, game port...

Mice as a mass phenomenon came up around 1984, when every PC user wanted to point and click like on a Mac.
The "signals" were not standard at all in the beginning.
Logitech and Mouse Systems were the most-known mice protocols that were incompatible to the M$ protocol. And then the varieties: incompatible bus mice, COM port mice and later PS/2 mice.

If you didn't rely on a standardized driver, you would shift the responsibility of implementing the driver to software developers. Essentially every game or application would need to include the same stuff anyway.

You absolutely can bypass the need for mouse.com and talk to the mouse directly if you absolutely want to, but by doing so you are effectively implementing a mouse driver, just like by writing code to talk to the SoundBlaster, you are implementing a SoundBlaster driver. So why would you?

By doing this, you're introducing a lot of headaches that you as a software author now have to deal with instead of focusing on writing your game/app. Where is the mouse, for instance? COM1? COM4? PS/2 port? Bus mouse? The standard mouse driver interface makes it so you don't have to worry about any of this, you just talk to the mouse through a well-defined standard interface. This is a Good Thing™

This is also why lots of games didn't talk directly to the SoundBlaster, for instance, instead relying on middleware abstractions like Miles Sound System.