This is very very sound advice. How many _actual_ data structures are there in our day to day? Trees, graphs, buffers, arrays, hashmaps, state machines... Yet we tend to overspecify operations as if they are special (see: many applications of OO), when they really aren't.
Another angle to look at this is moving complexity and specificity into data and away from functions. It's a recipe for success: HTTP/REST, SQL, CLI utilities etc.
Some of them are pretty obsolete, reflecting old conflicts and languages that are no longer in use, or obsolete due to hardware advancements, like the quip about lispers not caring about computational performance.
But that one is very good advice. A data structure that can represent a tree and be used with filter/map/reduce (e.g. list or array) can get you very far, and the functions can carry semantics instead of names attached to the data.
> 9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.
I'm sure that isn't always the case. At the very least, it shouldn't lead to mixing data structures.