No, I love objects.
But language features should be used where they bring value, not randomly because they're there.
First of all, I have no problem with immutable stuff, I don't even consider that state.
Mutable object state is fine too, as long as it in fact reflects the behaviour you're modelling. But it should be pared down to that. Not absolutely religiously, but it is a good ideal to strive towards, right up there with high cohesion and low coupling.
Many litter their objects with instance variables that do *not* model the core state of the object at all, but rather serve as a 'nifty' way to pass data to functions with less typing. This makes the object more stateful, which just makes life more difficult all around: you need to know what has happened before to predict what a function will do, and so you depend on many more places in the code to be certain that any one piece does what it should. The logic becomes less readable, more bug prone, harder to alter without introducing bugs, and harder to verify with tests. And that's not even going into thread safety and parallelization.
Fighting all this is not fighting object orientation. If anything, some solution approaches can be considered *more* object oriented: if that param-list starts getting too long, rather than abuse instance fields as lazy params, group the params into sensible value objects, and you may find the new abstraction yields additional benefits: an avenue for better expressing function and intent, implementing validation and constraints, encasulating calculations and query logic from the client code where it only constitutes noise, into self-explanatory functions on the data object.