Sadly I don’t know about animation sequence evaluator nodes, but I can take a look. My animation blueprint knowledge comes mainly from studying the free ALS plugin in BP and C++. I’d have to dive into that node. Are those nodes supposed to connect how separate parts of the airplane animate in relation to eachother? Something tells me that a blend node would be wrong for that purpose but I don’t know enough about this one 
.
I’d probably store a lever “position” (or time in animation between min and max) as a float value, and read that float value on a part on the plane to interpolate an animation state for that part over the duration of an animation sequence for that part in specific. Basically comparing one curve to another, or one animation to another. (yes, it’s code based)
I’d blend if I want to get an average result of things instead of a pre defined animation over time.
Next I wonder how much you could avoid code driven animation. In true simulation you also have to deal with external forces. On the airplane (code, animation) level you could deal with the gear freezing, or gear misbehaving (even separating) at high speeds for example. But when you get to external forces you can’t (or shouldn’t) store all those in the animation system of the airplane itself. They’d be stored data on external classes (weather, atmosphere, temperature) or even local (airplane damage). Probably… it’s more code driven than you expect.
Some time ago I worked on a Pawn Movement Component to implement it as 3 parts. A reimagination of the character movement component. The 3 are: “pilot”, “movement behavior”, “Unreal behavior (setting position, depenetration, sliding etc.)”. Basically the pilot is aware of plane movement behavior and sends a request to get towards an intended result. External forces would work on the “movement behavior”, because the component is set up to listen to its own and external forces (observer pattern, working with delegates). The animation system would pull data from this system to generates its animations. In a non sim (just any arcade game) you can get away with pre made animations, but the more you move towards sim it becomes procedural. You’d still use raw data like curves or floats (like setting up datatables with plane movement behaviors defined over X amount of properties (floats, curves etc.)), but use animation sequences much less.
Some (very much) simpler cases you’d be better of with playing and reversing an animation montage on request (the click). I’ve always wanted to avoid animation montages and integrate all logic within the same state tree of the animation blueprint but that led to (engine) bugs.
Edit* ALS plugin does use the nodes, might be a valuable tool to check if you’ve done the implementation alright and if they do what you intend to do:
I built my own branch of it ported from 4.27 (my C++ version) so, if they changed anything, I still got the stuff I posted on the screenshot.