The answer's from before my time, but I do remember the original reasons.
It all stems from Microsoft's relationship with IBM. For DOS 1.0, DOS only supported floppy disks.
Many of the DOS utilities (except for command.com) were written by IBM, and they used the "/" character as the "switch" character for their utilities (the "switch" character is the character that's used to distinguish command line switches - on *nix, it's the "-" character, on most DEC operating systems (including VMS, the DECSystem-20 and DECSystem-10), it's the "/" character" (note: I'm grey on whether the "/" character came from IBM or from Microsoft - several of the original MS-DOS developers were old-hand DEC-20 developers, so it's possible that they carried it forward from their DEC background).
The fact that the "/" character conflicted with the path character of another relatively popular operating system wasn't particularly relevant to the original developers - after all, DOS didn't support directories, just files in a single root directory.
Then along came DOS 2.0. DOS 2.0 was tied to the PC/XT, whose major feature was a 10M hard disk. IBM asked the Microsoft to add support for hard disks, and the MS-DOS developers took this as an opportunity to add support for modern file APIs - they added a whole series of handle based APIs to the system (DOS 1.0 relied on an application controlled structure called an FCB). They also had to add support for hierarchical paths.
Now historically there have been a number of different mechanisms for providing hierarchical paths. The DecSystem-20, for example represented directories as: "<volume>:"<"<Directory>[.<Subdirectory>">"FileName.Extension[,Version]" ("PS:<SYSTEM>MONITR.EXE,4"). VMS used a similar naming scheme, but instead of < and > characters it used [ and ] (and VMS used ";" to differentiate between versions of files). *nix defines hierarchical paths with a simple hierarchy rooted at "/" - in *nix's naming hierarchy, there's no way of differentiating between files and directories, etc (this isn't bad, btw, it just is).
For MS-DOS 2.0, the designers of DOS chose a hybrid version - they already had support for drive letters from DOS 1.0, so they needed to continue using that. And they chose to use the *nix style method of specifying a hierarchy - instead of calling the directory out in the filename (like VMS and the DEC-20), they simply made the directory and filename indistinguishable parts of the path.
But there was a problem. They couldn't use the *nix form of path separator of "/", because the "/" was being used for the switch character.
So what were they to do? They could have used the "." character like the DEC machines, but the "." character was being used to differentiate between file and extension. So they chose the next best thing - the "\" character, which was visually similar to the "/" character.
And that's how the "\" character was chosen.
Here's a little known secret about MS-DOS. The DOS developers weren't particularly happy about this state of affairs - heck, they all used Xenix machines for email and stuff, so they were familiar with the *nix command semantics. So they coded the OS to accept either "/" or "\" character as the path character (this continues today, btw - try typing "notepad c:/boot.ini" on an XP machine (if you're an admin)). And they went one step further. They added an undocumented system call to change the switch character. And updated the utilities to respect this flag.
And then they went and finished out the scenario: They added a config.sys option, SWITCHAR= that would let you set the switch character to "-".
Which flipped MS-DOS into a *nix style system where command lines used "-switch", and paths were / delimited.
I don't know the fate of the switchar API, it's been long gone for many years now.
So that's why the path character is "\". It's because "/" was taken.
Edit: Fixed title - it's been bugging me all week.