Binary objects are obviously far more opaque than plain text when it comes to piping data between tools, and that is a negative thing for the reasons he just gave.
When your shell can decode these binary objects natively, they are not any more opaque than text encoded as a stream of ASCII or UTF-(8|16|32) bytes. PowerShell pipes btw work seamlessly with native executables and turn these objects into text so you can put a grep at the end of your chain of PowerShell (assuming you have gnu grep installed) to perform filtering the unix way. Powershell will turn text into an object (of type string), and the console spits out text in the end. You can redirect this text to a file.
In addition to all that, you have the ability to operate on .NET objects. You can compile C# and VB.NET classes on the fly. C# and VB.NET will let you call an unmanaged dll function (e.g. the equivilant of linking to a .so and making an API call). So I could write a script that call call any .NET DLL easily, and with a few lines of C#, call any unmanaged API call. That's really useful. Whatever isn't exposed to me as a PowerShell cmdlet, I can access with not a lot of code.