Oh, certainly. But there are lots of cases in which it isn't.
.
Simplified version
A tour de force! I'm very impressed.
But honestly, both versions are unreadable, imho. Fortunately, we now have a primitive (DISTRIBUTION OF, one of the options in the LENGTH OF block) to do this. :~)
Wow, @dardoro really pulled it off …
Still, @bh: I agree with you about readability - that’s exactly why I don’t believe much in the PIPE function’s added value over other mechanisms.
My point is that you can't take a bizarre example that's unreadable no matter how you program it, and use it as an example of what's wrong with PIPE. PIPE does fine on reasonable algorithms. It's just like the Unix shell's pipe feature:
sort foo | grep bar | head
It doesn't' work for every case, but it works a lot of the time, and when it does work it's elegant.
(Btw, dardoro's pipe solution cheats a little, because the point of PIPE is to replace nested HOFs, and he still has some of those. :~) )
It’s actually a perfectly useful function, organizing (not sorting) data by key; and a serious implementation. As for me a more or less readable version is:
Update
I found 
(from the Frequency Distribution Analysis library) to do more or less the same thing, and - admittedly - both a little better, and faster.
- DISTRIBUTION OF is not applicable, in this case.
- DISTRIBUTION OF is not documented (no on-line HELP or ref.manual description)
- Apparently, DISTRIBUTION OF compares lists by reference, not by content - which, in my view, is rather peculiar for such function:
I agree that your version is more readable! Although part of that is the long variable names, and those names could be used as the formal parameters of the functions in PIPE. But that tiny little gray spacer is very cute. :~)
Does (1) mean something other than (3)? If so, could you please expand on (1)?
Yeah, (2) is my fault; I'm going to try to get the manual up to date by Snap!Con.
I imagine (3) is Jens's effort to make the block super fast, but I'll enquire. I agree that testing with EQUAL might make more sense in this context of grouping, but EQUAL is way slower than IDENTICAL, not only for lists, but because of case insensitivity.
By the way, not sorting the keys makes the whole thing take 𝜽(n²) time, because you have to search the entire input for each key, whereas if you sort the keys you can do it in 𝜽(n log n) time.
Updated code
I'm going to try out. Thanks!
Update
It appears to work (though generating an extra ring around each result, which can easily be fixed), but I don't understand why. Could you try to explain it to me?
By now I fixed the problem inside the code itself. Still I'm curious as to your quick fix, how it works.
Thank you; it's simply a do-nothing block named $nl (= newline). I found it to be useful for dividing code into some kind of paragraphs, for readability purposes. 
DISTRIBUTION OF reports the number of copies of a data element, the whole of each data element is considered key; both my GROUP BY function, and the similar block from the FDA library, operate on key-value pairs, considering key only item 1 of each data element, and grouping all data elements with the same key.
This dichotomy is completely different from the one between reference (memory position) and content (data).
Then why not offer two separate (and well-documented) DISTRIBUTION OF functions: one superfast but with limited functionality (to be applied primarily on lists with atomic elements), the other for general use but slower? Plus some way to indicate case (in-) sensitivity with the second version.
(the same reasoning as applies on the current superfast implementation of REMOVE DUPLICATES) 
True. I chose not to sort, so as to keep the solution as general as possible (sorting is not trivial for (sub-)lists, command blocks, and some more). However that may be, now that I've found the GROUP BY block in the FDA library, I've concluded my own version to be redundant.
im working on something like that w/ metaprograming blocks rn :D
No, its cool, but i wanna make my own cuz its fun
That’s a perfectly good reason.
I’m looking forward to see your version.
Good luck, and have fun!
Weird, i thought you guys know snap better than newbies like me. For me snap is a mystery, so idk why it works xd
I’m not sure if that isn’t irony (that you didn’t indicate it doesn’t mean it isn’t, is it?)
You’re doing pretty advanced stuff for a newbie - in a few months you may be viewed as an “expert” yourself.
We do; one's a primitive and the other's in a library. ;~) But I'll try to remember not to remove the library one, and to improve the documentation.
Which library would that be?
I found a version in the FDA library, but it, too, considers reference, not content:
Oh, I thought you had said that it meets your needs. Sorry.