I see two intertwined issues:

1. We shouldn't have to rewrite a skill wrapper for use with plan_execution or for use with SMACH. Skills should largely be immediately usable in either setting. Boost Python might offer us a way out, but it's difficult to imagine because ROS node handles and other resources still can't cross the Python/C++ barrier. We have a hacked solution in place to make it easy to wrap a SMACH state machine as an actasp action (works by wrapping the SMACH state machine into a separate process, providing a standard ROS action interface). So we can can kind of do Python code reuse in C++.
2. We don't have a good way of writing state machines in C++ right now. Many of the GUI skills (and others) are best expressed as state machines. We could migrate them to Python so we could use SMACH, but then we'll run into 1.

I'm not really sure how to address 1 well, but I think the solution should be shaped by going through 2. If we have a good way of writing state machines in C++, we can write our skills and skill wrappers in C++, then rig Boost Python to project a python State subclass that taps a ROS interface around the state machine.