In a lot of this, I see you trying to frame the argument as "should we do mTLS or should we do no TLS at all". And while there are threat models where TLS doesn't make any sense (Halvar's same-host or same-rack K8s model), I don't think people are generally advocating against encrypting network traffic. Encrypt your network traffic. Obviously, you don't need mTLS to do this.

Another sleight of hand I see here is the ambiguity between network authentication, service authentication, and user authentication. When it's convenient for the argument, it seems, mTLS is just a way to ensure both ends of a network connection are part of the super best friends club. But later, when it's helpful to argue that mTLS is "flexible", certs carry credentials. Maybe even JWTs! There's a subtext to the "be wary of mTLS" argument, and it's that unified site-wide PKIs don't work well in practice.

Finally, you've lost me completely with this "revocation is less critical to the threat model than you think it is" stuff. The step-ca website is even explicit about this distinction you're trying to draw between "active revocation" and "passive revocation" (short-lifetime certificates). No. That doesn't work in internal application environments. step-ca defaults to 24-hour certificates. Have you considered how weird that is? 24 hours is short enough that your CA needs to be highly available --- ask around about production outages that have been caused by certificates expiring at much longer lifetimes --- but long enough that you can't possibly "wait out" a compromised cert.

I feel like something that is happening here is that WebPKI-style mTLS advocates think that a server cert and a client cert are two different instances of the same thing. They are not. They are wildly different entities. A server certificate prevents a MITM active attacker from intercepting a TLS connection. That's a rare attack, and, more importantly, a second-order attack. A client certificate is an access token for the application. Lose a prod-viable SSH key and then tell me I should wait 7 hours for it to expire.

The reality is that every application that deploys "passive revocation" is ultimately going to have to implement "active revocation", and, if they follow the advice on the step-ca website, they're going to have to do it on no notice, and in the most disruptive way possible, because when an internal access credential is lost, it has to be shut off immediately.