I think refactoring to create a new class is a good solution to the state problem. That is, if you have code like this:

    func drive(Engine e, Destination d)
    func park(Engine e)
    func start(Engine e)

You can create a new class

    class Car {
        constructor Car(Engine engine)
        func drive(Destination d)
        func park()
        func start()
    } 

Which accepts the shared argument in the constructor. That way within the Car, you should have minimal state, and defining new functions can reuse the shared argument that the Car was constructed with: no more long argument lists.

A Car was sort of an obvious example but applying that pattern allows me to see less obvious examples, where a class is some abstract entity that I wasn't aware of before.

I think there's still fear of undisciplined state management in large classes, but that can be addressed with good SOLID class organization.