I think it very much depends on what problems you're trying to solve and whether or not proper data types have been defined.

If your primary data structure is

  Map<Integer, List<String>>

we have a huge problem.

On the other hand, if your primary data structure is

  Map<CustomerId, List<Purchase>>

Then I'd rather see that than IPurchaseMappingByCustomerIdAbstractFactory or whatever other abomination OO priests will conjure. Generally speaking, generic structures are simpler and they allow for easier transformations.

The article doesn't explain, but links into a deeper one. The author really means you should use Map<Integer, List<String>>.

He also seems to be unaware that you can have generic code with specific types.

You can still use types, as long as they don't encapsulate the data. Admittedly this is hard to do in some languages.

I am not entirely sure that most data-oriented programs do go this way. You can split functionality out of the data but the data can still be represented with an object or whatever. I would agree though, you might as well be using Python at that point.

An example of what I mean is Spring. Obviously, from what I recall, that goes to other extreme with lots of XML configuration. But there is no need for vague types that can cause all sorts of mischief at runtime. The key idea is splitting code from data, not necessarily the representation of the data (although that can come into it if you have performance-sensitive apps).