So I agree that enormous blobs of unreadable crap are indeed unreadable, and that regardless of how neat and functional your code is, it can still be complete gibberish to most people. That being said, long chains of streams can be broken out quite nicely by using intermediate names:
e.g.
Comparator<Transaction> descendingTransactionsByValue = comparing(Transaction::getValue).reversed();
Stream<Transaction> groceries = transactions.filter(t -> t.getType() == Transaction.GROCERY);
Stream<Transaction> sortedGroceries = groceries.sorted(descendingTransactionsByValue);
Stream<Transaction> transactionids = sortedGroceries.map(Transaction::getId).collect(toList());
vs. the first code block under "Figure 1" in the linked article.For me at least, it helps keep code from getting too unruly: you only have one 'thing' you can do in a filter, map or sorted call, unlike in a foreach loop where anything can go. So my thesis is this: using streams I can quickly scan over the function/stream names to get the gist of what it's doing, but using foreach loops I need to closely examine each line to have any idea of what's happening :3 (e.g. people love abusing labeled breaks [1] in our codebase, as well as excessively modifying input parameters w/o documentation, so I might be a bit biased against for loops)
[1]: https://stackoverflow.com/questions/14960419/is-using-a-labe...