FSM State implementation — SO, SO+wrappers, custom classes?

I've been wracking my head about this for a couple weeks, so maybe, just maybe, someone could chime in and point me towards the right direction.

My FSM design was initially based on Scriptable Objects for States using the Observer pattern - basically all state data lived on the State machine script and states modified/fetched it through 'owning FSM' reference.

Then I felt the need to implement state queuing, which meant that States could no longer be stateless, they had to contain individual state data. Since Scriptable objects are shared data, I went ahead and devised a 'StateWrapper' class. It contained data for a particular instance of a State and referenced the Scriptable Object that contained the State logic (already getting complicated, huh?).

Next question became obvious - why can't I ditch the Scriptable Objects altogether and just implement States using custom classes. Short answer is - preinitialized States. For debugging purposes I want to be able to 'initialize' some State instance with data (for example, setting the Waypoints inside a Patrol class). It's very easy with Scriptable Objects - I just make a copy of SO, drag and drop Waypoints into the corresponding Scriptable Object field, and then drag this "preinitialized State" into Starting State field, that's it. I also have "Compound states", which are basically State containers (Scriptable Objects, holding a list of State Scriptable objects and executing them sequentially, for example, "Interact" compound state is a State Container that contains "Move" state, "Wait" state and "Use" state in one package - it moves the character to target object, pauses a little and then uses the object). So all of the above is nice and dandy with Scriptable Objects, but I still wanna ditch the unwieldy "StateWrapper class + State Scriptable Object" construction. I now have two things I'm thinking off:

1. Make State Machine use INSTANCES of Scriptable objects, i.e. each new State would be created using "Instantiate(StateScriptableObject)". This way the States could contain instance data and be stateful. However I'm not sure if creating Instances of Scriptable Objects is feasible from performance point of view (I suspect this operation might be slower than instantiating a custom class through 'new' keyword, and that could be a problem). There might be other pitfalls with this approach.

2. Refactor states into custom serializable classes and write a Property Drawer for them, use custom editor/editor window for the ease of debugging/initializing states. I'm not sure about this one either, won't I be, in fact, reinventing the Scriptable Object? Any insights/hints would be greatly appreciated.

UPD: Ok, so I've benchmarked 100 000 Instantiate Scriptable Object calls vs 100 000 "new StateClass" calls. It seems like "Instantiate SO" is significantly slower (Time elapsed = 00:00:03.453288 vs 00:00:00.0230978). I guess this answers my question.