Why include the Segregated Witness Merkle Root in the input field of the coinbase transaction? I just read this article to understand SegWit better: https://bitcoinmagazine.com/articles/segregated-witness-part-how-a-clever-hack-could-significantly-increase-bitcoin-s-potential-1450553618/ There's a part that doesn't quite make sense to me:

But there is one problem: If signatures have no effect on the makeup of the blockchain, the blockchain no longer serves as proof that the correct signatures were included in transactions.
To make sure that signatures are embedded in the blockchain regardless, a Segregated Witness-enabled miner adds a trick, too. Rather than creating only a Merkle Tree out of all of the transactions, it also creates a Merkle Tree out of all Segregated Witnesses, to mirror the transaction tree. The Segregated Witness Merkle Root, then, is included in the input field of the coinbase transaction. As such the Segregated Witness Merkle Root changes the transaction data of the coinbase transaction, its transaction ID, therefore influences the block header and, ultimately, the makeup of the blockchain.

Is this accurate? If so, what exactly does it achieve?
Including the merkle root of the transactions in the block header prevents tampering with the transaction list, but I don't see any value in tampering with the signatures.
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).