I searched this list before I asked and couldn't find anything.
Anyway, I understand from Nick's response that len() is conceived for collections which have a size computable in constant time (I suppose structures that maintain some inner attribute to store their length). I also believe that "length" sounds more like an attribute name than a name for something which really does some computation ("count" sounds more appropriate for that). On the other hand, it doesn't seem to be a general concern not to provide construction which can lead to hidden complexity cost (like "in" used on a list vs a set).
The collections.abc module attempted to retroactively codify the standards for these things. All containers support in, which implies that you can't expect better than linear (even though some subtypes might provide logarithmic or amortized constant). Only sized containers support len, which implies that it should be constant time.
It might have been better if the 1.x designers thought through all of these issues ahead of time (as the designers of C++'s STL did), but what they came up with semi-accidentally (of course not really accidental, because Guido and friends had experience to guide their choices even when they didn't rigorously think things through) seems pretty good to me. At any rate, it seems far too late to change things that have been consistent since before 1.0 even if alternatives _would_ be more logical a priori. If you design a new language, you might want to provide separate operators/methods/functions for a log-or-better contains and a may-be-linear contains, and likewise you might want an operator to directly do may-be-linear indexing instead of having to write next(islice(…)), or you may not, but I don't think you can expect such things in Python.