That seems to fit the definition of leaky abstraction (an implementation detail influencing whether how you use it). Leaky abstractions are all over.

That same logic would suggest that we should name our methods Model.foo_slow() and Model.bar_fast() because the execution speed is important and should be transparent to the caller.

In practice, Model.foo() ends up often being memoized so that all but the first call are practically equivalent to accessing an attribute.

This won't work because it is not refactor proof. What happens when your system changes and Model.bar needs to become a method that does computation.

Your suggestion violates the uniform access principle: http://en.wikipedia.org/wiki/Uniform_access_principle

Any performance issues (which you brought up before the edit) should be entirely the concern of the class whose method is causing the issues. Anything on the outside shouldn't have to rely on syntactic clues to discover when something may be slower.

If I care to call person.eye_color, I don't care (as the caller) how Person implements eye_color (it may be a simple attribute or do some ridiculously slow color calculation) - if I need the color, I need the color. Now, that's not to say that performance doesn't matter, just that any performance concerns should be addressed in Person, not in trying discourage caller from calling eye_color and trying to get at that value some other way.

RubyMine at least will complain if you put the() after a method that doesn't need it. Coming from C# that lack of differentiation kind of irks me.