MITM is kind of a silly term for what the computer owner is doing when using a forward proxy. If the computer owner binds the proxy to a localhost address, the unencrypted requests need only go over the loopback. There need be no unencrypted requests travelling over the LAN. The computer owner, the "MITM", is on their own computer sitting in between an application and the network interface. That is exactly where they should be, IMHO. Corporations do it. They own the computer and they own their internal networks. It's no different for home users. And WFH is blurring the distinction anyway.

Once the requests leave the computer and travel onto the internet destined for another computer, then of course "MITM" makes sense as a concept. We all want to prevent that.

The computer owner controls the proxy and it's the proxy, not the untrusted application, like a "modern" web browser for example, that handles authentication of the remote peer. Compiling and fully controlling a "modern" browser is a PITA. Almost no one does it, even software developers. Instead people beg for an advertising company or their partner to make changes to a browser. That does not seem to work. Sometimes when people complain it stops the company from making undesired changes. But only temporarily.

Whereas compiling a proxy is easy and the user can fully control it.

Having used many different applications that implement support for TLS, I actually trust the proxy's implementation more than most applications. It's arguably easier to audit one program, the proxy, than it is to check every application to make sure the developer didn't make a mistake when adding TLS support. I recall socat as one example. That mistake went undetected for a long time. Elinks was another. At the time, it was dropped from OpenBSD ports as a result.