Let me guess, you prefer methods called "getLength" over methods called "length", right?
"Method names should be verb phrases" is one possible convention, but it's not the only convention. If you can get better code by violating that convention, then the convention is, in that instance, wrong. Using verb phrases for function names is more of a procedural programming technique that doesn't always translate to object-oriented programming. In this particular instance, having a more declarative interface is more readable.
Distinguishing between attributes and methods in your interface violates encapsulation. The only thing an object's interface should be worried about is what messages it responds to, it shouldn't have to expose whether it responds to messages by fetching a variable or calling a procedure.
On the implementation side, if you just want to expose a variable then attributes are fine. Outside of your object, though, who cares whether or not "length" is an attribute? Maybe your object is encapsulating a lazily-evaluated database relation, at which point "length" would generate a SELECT COUNT query. It still fulfills the contract of "an object that has a length", and you don't want to get in the business of defining different interfaces for "an object that has a length cached in an instance variable" and "an object that has a length that is calculated dynamically".
The properties of an object are best expressed with noun phrases regardless of their implementation.
Objects are nouns. They have attributes. Some of them can perform actions. Those actions ("verbs") are methods. It doesn't make sense to ask a noun to perform "where" or "length". Which part of this is confusing?
It's not confusing. It's just less useful. If you think of objects as having attributes and methods, you're just treating objects as bundles of functions and variables you can pass around. In essence, you're still doing procedural programming.
It's much simpler and more effective to think of objects as things that respond to messages. So instead of thinking it as asking the object to perform "where" or "length", think of it as sending the message "where" or "length" to the object and potentially receiving a response. This way you can expose more flexible and declarative interfaces, and let the object worry about which properties it computes on demand and which properties it caches or stores in instance variables.
You do have to consciously do this in C-derived languages, though. But it's easily possible.
I'd rather not introduce event-handling semantics to a list of strings. It's easier to add a 'filter' method. Granted, a distributed task queue might benefit from this, but I'd still rather not have it baked into everything.
In a sense, but message passing is the basic concept of object-oriented programming. Choosing which messages to receive and respond to is defining an interface. If you don't want to do that, you just don't want an object-oriented list of strings. Maybe you just want a list of strings that lives in a struct with some function pointers and some syntactic sugar for calling those functions. And that's fine. But for those of us who do want an object-oriented list of strings, allowing that list of strings to respond to messages like "where" is perfectly acceptable, and certainly no worse than demanding that it only respond to messages like "filter".
If anything, it introduces unnecessary semantics to syntactically distinguish between messages that are responded to with instance variables and messages that are responded to with function calls.
"Method names should be verb phrases" is one possible convention, but it's not the only convention. If you can get better code by violating that convention, then the convention is, in that instance, wrong. Using verb phrases for function names is more of a procedural programming technique that doesn't always translate to object-oriented programming. In this particular instance, having a more declarative interface is more readable.