That is completely incorrect.
No it's not. Like I said, the MITM device does the cert validation with the actual endpoint. The client does cert validation with the MITM device. The cert chain actually associated with the endpoint doesn't make it to the client unmodified, which means the client can't make any useful security decisions when validating it. All meaningful cert validation decisions are made by the MITM device.
Its your employers machine; id say he has the greater right to decide which SSL certs are and are not trusted. If you need to connect to the DoD, your employer almost certainly knows about it, and if he doesnt you should probably let him know.
The real problem was tricky to summarize in one sentence. By having the MITM do cert validation, it means you can only use one set of trusted roots for all connections on your network: the one installed on the device. This is frequently the wrong behavior, though. I have a computer here that needs to make SSL connections to DoD computers, and so I have their root cert installed as trusted. I have another computer here that doesn't need to make such connections and so doesn't have the root cert installed. If I see a connection signed by a DoD root on that machine, it will fail to validate, correctly, because it's an error. This gets uglier if you want to trust, say, a single self-signed cert or internal root cert. It's best to restrict trusting those to as few machines as possible.
I'm not even trying to get into whether an end user wants to trust things that their employer doesn't. Forget that. It's solely from the perspective of an IT staff trying to minimize the risk of computers on their network making bad SSL connections. A single set of rules at a central location is not ideal.
90% of your objections are basically that a dedicated IT team is writing the security policy (what crypto algos to use, what CAs to trust, etc) rather than you getting a say in it. Guess what: thats not your job, and the employer has every right to enforce the security policy of his choosing. It may even be a legal requirement for him to do so.
Well, it is my job, so I get a say in it regardless. But that doesn't matter.
Despite the fact that most users don't pay attention to these things, delivering bad security information to the user is still harmful. The user has a huge advantage over an automated tool, because they know what their intent was. They can notice (though probably won't) that, for example, their SSL connection to a DoD machine really should have been signed by the DoD root and not by a CA in Turkey (just for example).
That's the lesser issue, though. The problem is that it breaks the ability for software systems to improve certificate validation security. Does your software application use certificate pinning? Too bad, we're rewriting the cert chain! Does Chrome update its CA revocation list 4 weeks faster than your MITM product's vendor in response to a CA breach? Too bad, you're stuck with whatever CA list is in that product! Does your software happen to know that it should never, ever be communicating with a cert signed by a CA that uses only MD5? (My software does, because I'm buying the certs that's on the other end!) Too bad, they won't disable it in the MITM device because it would break half the Internet, and the trusted internal CA of course uses SHA1, so that validates!
It's a terrible technological hack that reduces the ability of the client to make important security decisions. If your employer wants to control how you validate certs, fine. They should control the configuration and software on the computer. If they want to monitor your SSL connections, fine. There are legitimate reasons for that. They should use an actual standard for proxying SSL connections that conveys all of the security information back to the client.