Josh Bloch argued against the interface solution in Java (and in particular, read-only versus read-write interfaces), claiming there would be too many interfaces and it would confuse users, and that didn't sit right with me. To me it's his second-biggest sin against Java, and it's tied to the first.
The only truly unforgiveable one is UnsupportedOperationException. The guy who wrote the collections API for Java didn't know the first thing about the Liskov Substitution Principle, and gave the world an implementation that violates it because the alternative would have been too difficult for people to understand? Rot in hell forever, Josh. And take your Effective Java with you to throw on the pyre. I can't write effective Java and it's partly your fault.
At the time I was experimenting with my own language API design, so I sat down and figured out how many interfaces it would take. I came up with around 20% more than the selected design. You'd think it would be bigger, but the critical observation is that a lot of generic collections vary only on write operations.
Read operations are often identical, and if the surface area for reads is small, then a functional programming style is more reasonable. Which may explain why so many functional programming languages appear to other people to have an anemic collections API. What I'd love to know is if any of them use different implementations under the hood for small sets/lists versus large ones. If they do, I don't hear anybody bragging about it.