Without the ability to string multiple, focused tools together even tools that did one thing well(i.e., Evernote) will continue to add features until it does a bunch of things meh.
On the web, "|" (pipe) means integration with other services, and it comes with all the associated trials and tribulations. To make web pipes work, just to even get started, you first have to solve authentication and data format/transfer standards. Those things are a big pain, its not surprising that most services attempt to provide the service directly.
Unix pipes were designed for builders, technical people who understand the structure of the data they're piping around. Posix commands come in a minimum standardized set that work well together, and while there are some commands here and there to pipe structured and/or binary data, the core set and what most people use pipes on and love pipes for is plain text.
The internet just doesn't have the same foundation or purpose or user base, its usage is not centered around technical people building pipelines, so its not surprising that web services by and large haven't flocked to meet a unix analogy -- its technically much harder to do than writing unix, and its not even clear its even close to a useful thing to do, for most people.
The web has a variety of other content types - images, videos, applications, structured data - that don't map well to this model. Before you have interoperable webapps, you need to define common data formats for them to interop.
Also: ditch plaintext for structured data and suddenly handling of other content becomes much, much easier, and they map perfectly to this model.
Unix pipes have already solved the authentication problem. For instance, to stream a compressed harddisk copy safely between two hosts you can use the following statement:
dd if=/dev/harddisk | gzip -9 | ssh user@xyz dd of=hdcopy.gz