As Raffzahn explains, the clock device driver was added in DOS 2.0.
AUX, etc. were device names already present in DOS 1.0, some of them even earlier in CP/M; these names couldn’t be changed to preserve backwards compatibility. Of all the standard (in-kernel) device drivers,
CLOCK$ is the only one which wasn’t already present in DOS 1.0.
An important subtlety in DOS is that opening a file or device (interrupt 0x21, service 0x3D when using file handles) will open a device in preference to a file for any file name matching a device, ignoring the file extension. Opening
NUL.TXT etc. will all result in opening the
NUL device driver, not a file on disk. Thus, any new device driver effectively replaces any file using the same name, in any directory, regardless of extension.¹ CP/M required colons (
PRN: etc.) to identify device names, but this requirement was dropped in MS-DOS, which merged the namespaces.
As far as the clock device goes, DOS itself doesn’t care what the name of the device is; the clock device is identified by a specific bit in the device driver attributes (bit 3). The DOS reference manual mentions this:
MS-DOS assumes that some sort of clock is available in the system.
This may either be a CMOS real-time clock or an interval timer that
is initialized at boot time by the user. The
CLOCK device defines and
performs functions like any other character device, except that it is
identified by a bit in the attribute word. The DOS uses this bit to
identify it; consequently, the
CLOCK device may take any name. The IBM
implementation uses the name
$CLOCK so as not to conflict with existing
files named clock.
It would appear that the
CLOCK device name was chosen, and then someone realised that it would create conflicts with any existing file matching
CLOCK.*; to avoid that, the driver was renamed to
$CLOCK in PC DOS, and
CLOCK$ in MS-DOS (which was also the name used in DR DOS), but not before some releases ended up using that name in the wild.
Without this change, people with files named
CLOCK.TXT etc. on floppy disks would lose access to them when they switched from DOS 1 to DOS 2.
AUX etc. don’t have this problem because no one would ever have been able to create such files on a PC using DOS (except by modifying the directory entry directly on disk).
All this is the reason why installable character device drivers use variously-decorated names:
MSCD0001 and so on for MSCDEX,
EMMXXXX0 for EMM386, the list goes on.
¹ Ignoring both the directory and extension were deliberate design decisions. DOS 1 programs didn’t know about directories, and expected to be able to open devices anywhere (see “From a Feature to a Bug” on OS/2 Museum). Some programs (particularly those ported from CP/M) also forcibly applied their own extension to whatever was provided by the user, so extensions had to be ignored so that devices could be used (being able to ask a program to use
COM1 instead of a regular file could be very useful in some circumstances). DOS supports a Unix-style
\DEV virtual directory, but that never gained much traction.