I disagree: I think it would get very complicated. Suppose that instead of a Horse Traders, B had a Secret Chamber. While B is deciding his reaction to Margrave, A goes ahead and plays his next action, which is a Smugglers, gaining a Gold. ...
To do it perfectly would be very complicated, but the low-hanging fruit is what's important. I got a bit carried away with a more complicated example, but the important thing is what happens often, like waiting for three people to discard sequentially. You can go on the safe side all the time, and then start making exceptions for that which matters the most (and still isn't too hard to do).
With your Smuggler example, when a list of cards possible to gain is created that perhaps isn't returned until some kinds of events on the queue are gone. There
could be more of less complicated rules looking at the queue to see if there is anything there that
might empty the Gold pile, but there could also be a general simpler rule "oh, you want to gain a card? that's so complicated so we should have an empty queue except for harmless events of types A, B and C" first.
Somehow the game server would have to figure out that it was theoretically possible for the rules to be violated and disallow A's action. I'm sure it's possible to do this for all possible cases with a complicated enough set of logic; however, if this were implemented it be both confusing to the players. For example, player A can't play that Smugglers in this case, so he'd be scratching his head wondering why.
I think A should be able to
play Smugglers. What A might notice is that he can't pick what card to gain immediately. Still, the interface all this time shows that it's waiting for B to act. When B is really slow I agree there can be scratching. You understand that it is B that is slowing the game down, but it would seem like you got to do half a turn anyway. When B isn't really slow, but only slightly after the others, it will only be noticeable by everything being more smooth.
A much more manageable idea, which has been kicked around before, is just to allow players to start to respond to attacks (and Masquerade) out of order, even though the responses will be re-played in order. It certainly would be nice people if everybody could just start discarding their cards or revealing their Moats, as people often do IRL. This still has complications. For example, if player B and C can both discard and reveal a Tunnel, player B must be allowed to get the last Gold. (in which case player C will probably decide to keep his Tunnel in his hand anyway for his Upgrade) So there'd need to be bullet-proof rules set up for when asynchronicity would be permitted.
I don't see that as something totally different because it is used only for attacks. It's probably true that most of the low-hanging fruit has to do with those, but as you write there are complications with that as well, so I don't see that there is that much easier to use the framework only for those. There are things that aren't that complicated and would be nice that don't have to do with reactions, and would work with the more general queue. It would for example be nice if I could start playing my turn when the player before me is making choices about Stashes when shuffling in the cleanup phase. With the general queue that would follow naturally from that as soon as there is nothing the previous player can do that affects my hand I could play my first card.
I think it's fun to think of what can be done asynchronously, but it won't be perfect and there is no reason for it to be. Anything that might be complicated could just demand that the queue is empty before it returns. Then you could take one step more and make some things possible to do if there are only certain kinds of events on the queue, focusing on what seems to be most irritating then.