If using Google's BeyondCorp architecture as the definition of "Zero Trust"[1], it does away with traditional "defence in depth" redundancy such as implementing, in series, IPSec/Wireguard/TLS tunneling AND mutually authenticated application layer TLS to mitigate a single technology failing. Instead, network boundaries are removed and anyone can access internal system login pages across the Internet from a web browser[2]. In place of network boundaries, device attestation[3] is relied upon to ensure control over the state of devices that are being used to access the internal system.
I would argue that the "Zero Trust" definition in the BeyondCorp architecture is somewhat an opposite of "defence in depth" because it appears to advocate so many single points of failure. You have to trust the TPM manufacturer's claims. You have to be certain the software running the public facing login portal is free of remotely exploitable vulnerabilities. You have to trust your whole business on the source code of a single vendor providing the software for centralised user authentication. You have to trust the few employees who manage these single points of failure with an entire business rather than a small part of the business.
Defence in depth is either achieved by implementing systems in series, or in parallel.
Systems in series have decreased availability and thus have a downside of an exploitation in any one system in series being a more likely occurrence (larger attack surface), and upon an occurrence, the availability of all systems in series is impacted. For example, let there be two proxies in series from two vendors, each proxy performing deep packet inspection and analysis of files being transferred. To get a file transferred through both proxies, an attacker has to convince both proxies (independently implemented) that the file is not malicious, and thus it is harder to fool two systems rather than one. However an attacker can find a content parsing vulnerability in either proxy (double the attack surface) and use the access gained to more readily deny service, leak information or inject or modify information.
Systems in parallel introduce a larger attack surface and thus exploitation occurrences are more likely, but each occurrence has significantly decreased consequence. An example of such an architecture is different divisions of a business using SFTP, TLS or SMB protocols to transfer files, and different divisions using different implementations of those protocols in different software. An encryption vulnerability in one implementation of one protocol may only expose two divisions of the business, but the other divisions would not be directly impacted. It is likely that incidents occur more frequently as there is a much larger attack surface, but each incident has a less severe outcome.
[1] https://storage.googleapis.com/pub-tools-public-publication-...
[2] Example: https://login.corp.google.com/
[3] Example of how device attestation could work: https://www.w3.org/TR/webauthn/