Theoretically, it might be possible. But practical considerations should not be so easily dismissed.
What @supercat says is true. But part of another reason is already contained in your question: the VMM was not merely a host for applications written against the DOS/BIOS interfaces, it was also itself a client of those same non-reentrant interfaces. This was necessary to implement crucial backwards-compatibility features like the real-mode mapper (the 16-bit I/O driver layer). To be able to run DOS/BIOS code concurrently with other code, you’d need to ensure neither treads on the other’s invariants; I alluded to some of those problems in my answer about a BIOS hard disk driver in Linux. But to save on performance, and to preserve the behaviour of delicate timing loops, the VMM often ran BIOS code in ring 0, giving it full control of the hardware. And some DOS APIs were outright transparently forwarded from the virtual machine to the bare metal.
Of course, this isn’t necessarily insurmountable. As you say, you could simply declare that only a single thread of execution can talk to hardware directly or enter DOS/BIOS code at any given time. In fact, the necessary synchronisation primitive (the critical section) is already there. But that gets you all the performance problems of global locks that we used to know from Linux (the infamous Big Kernel Lock) and still know from CPython (the equally infamous Global Interpreter Lock).
Also, remember that Windows 9x targeted low-end hardware (well, at least lower-end than Windows NT did). Multiprocessing systems were nowhere near as ubiquitous back when those operating systems were being developed as they are today (my barely informed impression is that they remained next to non-existent outside supercomputing throughout the 90s). Implementing SMP support with fine-grained locking takes work, and it might have actually hurt single-threaded workloads (to the point where Windows NT, which did support multiprocessing, required running a separate kernel build in that scenario, just to avoid the synchronisation overhead on single-processor systems). The dearth of synchronisation primitives on early x86 CPUs did not help either. With no market demand for it, there was no reason to expend such effort.