This article presents a number of valid points to support end-to-end
argument in designing systems. The main claim is that placing
functionalities in low levels provides little benefit as opposed to cost.
This is certainly true for many applications. An application is aware its
specific requirements and type of service it is trying to provide. A system
that application is using is designed to be shared by many applications and
must provide services to all of them, thus implementing the "greatest
common divisor" of services that may be needed by different users. This
services must be general enough to be reused in different contexts and
can't compare in efficiency to a service tailored and fine tuned for a
specific use. Even if the system could provide a very specific
functionality it still doesn't have all the information that the
application has, so it can't do the job as efficiently. Low level
functionality can in many cases be redundant. In the example of
communication systems lower protocol layers could be pointlessly trying to
deliver packets (using retransmissions and checksums) of a file that is
corrupted, but this can only be detected in upper layers.

Putting functionality at the low level means that the system is providing
functionality that applications didn't ask for. This functionality can be
useful to some applications, but also harmful to others. Retransmission of
lost packets is a beneficial for applications dealing with elastic traffic;
but, because it causes unwanted delay, it is probably something streaming
applications would like to avoid. This leads to a point that is not
addressed in the article: providing low level functionality only when
demanded. Added services offered by the system could make application
development much easier and open to a broader public. Secure and reliable
communication offered by the system can protect users of substandard
applications that didn't make any provisions for this. Developers of more
sophisticated applications wouldn't trust the system and its
functionalities and they would re implement offered services, so ginning
them the option not to use low level functionalities makes sense.

The article gives a good overview of different scenarios where end-to-end
argument can be successfully applied and prove to be beneficial.
Generalizing this to all systems is somewhat more difficult and here the
article often refers to specific cases or states that the best solution is
a trade off. Without going into the details of this trade off the article
provides a strong motivation for considering end-to-end argument when
designing systems, but it doesn't give any immediate, ready to use, results
applicable to system design.