OK, after reading the linked Baldwin article above, I think I understand what you were getting at concerning whether static methods should be "independent". Following is an exerpt from that article, explaining static methods.
The method should probably also be self-contained. By this I mean that all information that the method needs to do its job should either come from incoming parameters or from final static member variables (constants). The method probably should not depend on the values stored in non-final static member variables, which are subject to change over time
The author is stating (without supporting arguments, unfortanately) that a static method shouldn't depend on the state of the class in which it is defined.
For the most part, this is a practice I see followed. Static methods are typically used as utility methods that are independent of the state of the system in which they are running. However, I also see the occasional use of a static member to do something like count instances of a class (in mostly contrived examples for educational purposed).
In general, going the object-oriented route and defining objects to represent the state and behaviors of a system is a good idea. For situations where only a single entity should track some state or provide some behavior, following the Singleton
Pattern is a recommended practice. For the occasional situation where a simple utility function is need to perform some calculation, a static method probably isn't the worst thing in the world, but use them sparingly. There are good reasons object-oriented programmers don't program function libraries as you'll find in c or php. That topic wanders deeper into the whole object-oriented principles and thinking realm. I'd recommend moseying on over to
the OO, Patterns, UML and Refactoring forum for such conversation.