The end-to-end argument says a guarantee can only be made by the endpoints that care about it. Its standard example is a careful file transfer. The receiving application has to checksum what it reads back from disk and ask for the file again if the checksum doesn't match. It has to, whatever the network promises, because corruption can happen in places the network never sees: disk, memory, the application's own buffers. So network-level reliability adds nothing to correctness. Why do networks check and retransmit at all?
Because it saves resending. Say a 1.5 GB file is about a million 1,500-byte packets, and each packet has a one-in-a-million chance of being corrupted. The whole transfer then has about a 63% chance of containing at least one bad packet. With only the end-to-end check, each failure means resending the whole 1.5 GB. A per-hop check fixes the same bad packet by resending 1,500 bytes over one link.
The middle layer isn't a different kind of thing. A hop that checksums and retransmits is running the same pattern as the application: check at its own boundary, retry within its own scope. A link checksum is end-to-end for the two ends of one wire; TCP is end-to-end for two sockets. Each layer gets correctness at its own granularity, and its guarantee stops at its own boundary. Only the layer whose ends are the real goal, here the file on disk, can guarantee the goal.
I worked out that self-similarity after going through the file-transfer example; I learned afterwards that the paper's section on identifying the ends warns that the argument depends on which endpoints you apply it to.
The paper is Saltzer, Reed and Clark, "End-to-End Arguments in System Design" (1984).