The example happens to use "munging" text, but I think the GP is trying to make the point that you can't use sed (effectively) to parse, for instance, a collection of database entries from an SQL server in the same way that LINQ would be able to do so.
The tl;dr I got from the article was LINQ is effective at working with sets of data; not just sets of text data from a text file.
True, although Plan9 pushed that part of the Unix philosophy even further, towards where it arguably handles some of those more general cases as well, with "structural regexes" that work on things other than collections of lines: http://doc.cat-v.org/bell_labs/structural_regexps/
Isn't the general consensus that regexes are hard to maintain and debug? I'm not sure that "structural regexes" are solving the right problem.
I think maybe we're not shooting at the same baskets though (basketball reference, apologies if you're not from US); I'm trying to write software applications, not shell scripts.
I'm sorry, but you're still missing the point. The point is that the syntax with LINQ is actually the same. Saying you have a program to do X in bash is the equivalent to saying you've got a library to do X in C# or Java.
LINQ, on the other hand, can work with arbitrary runtime objects and arbitrary backend implementations. Haskell's still cooler, though.
A tiny bit of knowledge of grep, sed, and awk, and other simple unix text utilities such as join, comm, cut, paste, goes a long long way.