Why a witness commitment is necessary at all: Enabling DoS prevention for validating nodes
Block validation is expensive. It requires hashing all data in a block, building Merkle trees, looking up all inputs from the UTXO database, running script and ECDSA validation, do various consistency checks, and updating the UTXO database. If random peers could make us do that amount of work, we'd be exposing ourselves to denial-of-service attacks.
Thankfully, producing blocks is expensive - it requires spending hash power. An attacker could take a valid block, and modify it before relay to turn it invalid. However, since all data relevant for validation directly or indirectly affects the block hash, doing such an attack will invalidate the proof of work. Thus, we can simply make sure that a block's proof of work is valid before doing any of the more costly checks, and that way we make sure that every attacker needs to spend new hash power for each block we try to validate.
Segregated Witness adds more data to blocks that is relevant for validation. In order to make sure that the protection outlined above still works, we must make sure that the new witness data affects the block hash. Otherwise, an attacker could simply take a valid block, make a gazillion modified copies, each with a different invalid witness, and broadcast them. Nodes would need to validate every version.
Why the witness commitment uses a Merkle tree: compact witness proofs
Some outputs (e.g. 1-of-2 multisig) can be spent by different combinations of signers. Certain wallet software may be interested in knowing which party/parties signed off on a spend for display or forensics purposes.
Lightweight nodes can currently request a compact proof for the existence of a transaction (see BIP37). As the witness does not contribute to the txid, the normal Merkle structure does not permit creating such a proof for the witness data. While there is currently no available protocol for requesting such witness proofs, using a Merkle tree for the witness commitment enables this.
Why the witness Merkle root is stored in the coinbase: easiest deployment for miners
Lastly, we need a place to embed the witness Merkle root hash that affects the block hash. Using the block header would have been perfect, but there is no way to add data there without breaking every piece of Bitcoin infrastructure.
The only place flexible enough for storing that data is in a transaction. A special transaction could have been added which contains the commitment, but transactions bring extra overhead. They need inputs and outputs, which need to come from somewhere and go somewhere.
Because of that, the only choice remaining was to embed the commitment in an existing transaction. The coinbase transaction is the logical choice - it is already created by miners anyway, and adding a dummy output to it has low resource costs (due automatic removal of OP_RETURN outputs from the UTXO set).
