A number of things would need to happen for this to be a viable solution.
First and foremost, the people who are using the escrow service need to fully understand how to validate that a multisig address is correct. If the users (aka the people who are trading) don't have a way of ensuring that the address provided is correct, then the person who provided the escrow address might as well have the private keys to all of the n that makeup the escrow address, or at least m number of the private keys (for a m of n setup).
Secondly, when dealing with this many people, a new address should be used for every transaction, which means that the escrow needs to either use a new key for each transaction, or the two parties of a trade should provide their own key for the specific transaction. If it is the later then once the goods are received, both parties can simply sign a transaction sending the BTC to the seller and the escrow is never involved. If it is the former, then there each of the escrows will need to keep track of, and back up a large number of keys, which increases costs and the required amount of time involved. In both cases, there is a lot of room for error on multiple fronts.
There is also the issue of ensuring that all parties involved (eg, all the escrows, and both parties to the trade) full agree to and understand the terms of the trade. If one of the escrows does not understand the terms of the trade, then they are not going to want to sign a transaction releasing the escrow, especially if there is some kind of dispute.
It also needs to be understood that this is not a risk-free setup as a number of things can happen that would result in the loss of funds, among other things, there can be collusion between parties that hold sufficient keys to sign a transaction. Having this many people involved also increases the risk that someone will make a mistake.
There is also the issue of time. Getting this kind of escrow setup is going to increase the amount of time it takes for an escrow address to be provided. This is a problem because people who are trading are often impatient. I cannot even count how many times I was trading with someone who ended up deciding they wanted to send first to me because escrow took "too long" to respond to their request.
There is also the issue of liability that needs to be addressed. Escrows are not going to want to check behind others to make sure they did not make a mistake. It is also possible that multiple escrows make a mistake that might not have been made if they were acting alone, and none of the mistakes individually caused the loss of funds, but the collection of mistakes caused such loss of funds.
See, I really tried to setup a virtual 3 membered escrow network in my PC. Electrum gives n private keys for n people involved for the same public key. So, there's no possibility for a single person to have n keys with him, also, its a multi sig thing, how can one single person spend the funds?
Second, yes, this setup is tiresome but only for once. Once setup, it would be good and going. The m-of-n network provides great security too. There are nearly zero flaws. The only flaw I can see is that if 3-of-4 is setup, then at any point of time, 3 of them have to be present anyhow, which can be a problem. Dividing things into 50:50 is always a better idea (atleast in a 4 people network). If its 5 people involved, then 3 signatures are fine.
Also, all the addresses will be same on all the n wallets of the n people involved. There's no way to generate a address on your wish in electrum. It only generates new address if you used up all the addresses it generated. And also, it is a deterministic wallet, so all you need is your seed and for a multi sig wallet, you need the master public keys of the n people involved to restore your wallet.
This is all you need to take care of and everything's good. But since this being a tiresome thing, the charges will be higher. It can be static or dynamic fee structure depending on the type of trade or it can be decided by the escrow providers.