Short answer: managers want a simple, testable, PROOF of function before committing to millions (or more) dollars to a design. Current tools, just do not give asynchronous designs those answers.
Microcomputers and microcontrollers typically utilize a clocking scheme to insure timing control. All process corners have to maintain timing across all voltage, temperature, process, etc effects on signal propagation speeds. There are no current logic gates change instantly: each gate switches depending on the voltage it is supplied, the drive it gets, the load it drives, and the size of the devices that are used to make it, (and of course the process node (device size) it is made in, and how fast THAT process is actually performing --- THIS pass through the fab). In order to get to "instant" switching, you'd have to use quantum logic, and that assumes that quantum devices can switch instantly; (I am not sure).
Clocked logic makes PROVING that the timing across the entire processor, works across the expected voltage, temperature and processing variables. There are many software tools available that help measure this timing, and the net process is called "timing closure". Clocking can (and, in my experience, does) take somewhere between 1/3 to 1/2 of the power used in a microprocessor.
So, why not asynchronous design? There are few, if any, timing closure tools to support this design style. There are few, if any, automated place and route tools that can deal with, and manage, a large asynchronous design. If nothing else, managers do NOT approve anything that does not have a straightforward, computer generated, PROOF of functionality.
The comment that asynchronous design requires "a ton of" synchronizing signals, which required a "lot more transistors", ignores the costs of routing and synchronizing a global clock, and the cost of all of the flip-flops that clocking system requires. Asynchronous designs are, (or should be), smaller and faster than their clocked counterparts. (One simply takes the ONE slowest signal path, and uses that to feed back a "ready" signal to the preceding logic).
Asynchronous logic is faster, because it never has to wait for a clock that had to be extended for another block somewhere else. This is especially true in register-to-logic-to-register functions. Asynchronous logic does not have multiple "set up" and "hold" issues, as only the ending sink structures (registers) have those issues, as opposed to a pipelined set of logic with flip-flops interspersed to space the logic propagation delays to clocking boundaries.
Can it be done? Certainly, even on a billion transistor design. Is it harder? Yes, but only because PROVING that it works across an entire chip (or system even), is much more involved. Getting the timing on paper is reasonably direct for any one block or sub-system. Getting that timing controlled in an automated place and route system, is much harder, because the tooling is NOT set up to handle the much larger potential set of timing constraints.
Microcontrollers also have a potentially large set of other blocks that interface to (relatively) slow external signals, added to all the complexity of a microprocessor. That makes timing a little more involved, but not much.
Achieving a "first-to-arrive" "lock-out" signal mechanism is a circuit design issue, and there are known ways of dealing with that. Race conditions are a sign of 1). poor design practice; or 2). externals signals coming into the processor. Clocking actually introduces a signal-vs-clock race condition which is related "set-up" and "hold" violations.
I, personally, do not understand how an asynchronous design could get into a stalled, or any other race condition. That might well be my limitation, but unless it happens at data entering into the processor, it should NEVER be possible in a well designed logic system, and even then, since it can happen as the signals enter, you design to deal with it.
(I hope this helps).
All that said, if you have the money ...