My thinking may be affected by having got used to how blueprints work, but first and foremost I’m a programmer, and I find the idea of that graph printing the initial value twice extremely counter-intuitive.
You seem to essentially be saying that all nodes be executable nodes under the hood, just that the ‘pure’ ones be implicitly plugged into the execution chain at the point that one of their outputs is first used? What about when a getter node was used from disjoint (asynchronous) execution paths in an event graph - when does it get reevaluated? Or behaviour changing as a result of cutting a value wire in a different section of the graph? I think this would introduce far more issues than it solved.
I agree there are issues in BP with unexpected reevaluations of pure nodes that can lead to performance concerns, but personally I don’t think BP performance should be a top priority. It was never intended as a full substitute for C++ anyway.
For me a bigger BP issue is the fact that node pins in event graphs behave like class scope variables. This leads to at least two issues - 1. recursion in event graphs is a no-no; 2. a blueprint will (generally without user intention) retain a strong reference to a UObject that at any point passed through a pin on its event graph, until either the pin value is overwritten, or the blueprint instance is destroyed. The latter had me stumped for a fair while, and could in some cases cause a significant memory/resource problem.