I don't like it. It's just a more limited UI for defining logic which is normally determined by events.
I would say - not logic, but behaviour - the logic is still in events, you either turn it on or off or adjust settings, just like behaviours. In fact these are basically behaviours, just with more freedom of interaction and visibility.
Whether you have a movement, oscillation or just a clamp, often you don't want it to apply all the time. So you need to be able to turn it on and off or adjust the parameters in events based on other custom logic in the game. So you will have a bunch of events to modify all this stuff anyway. Now you have fragmented your logic between this UI system and the event sheet. If you went as far as to extend the flowchart system to do everything events have, I see it as an inferior system, since you have your logic spaghetti-fied in to 2D (whereas events are a 1D list, just going down the event sheet), which makes it very difficult to determine the sequence of things, which is an essential part of the game logic.
The current way allows you to apply, enable/disable and modify behaviors from the event sheet, where it is more or less all done already, with full flexibility to customise the logic and parameters, and it's all kept in the same place (no fragmentation).
The point here is that you would be able to do all the same things, but not fill your event sheets with, basically, non-events like: Set setting A to this, Setting B to that, Setting C to that, etc. If there was an event sheet command that basically brought up the behaviour panel the same as it is in the editor and you could just adjust the values and it automatically would leave only the affected ones then there would be no desire for something like this. As is I would say there's plenty of "event spagetti" just to set up some mildly random or reliant things.
This is basically the same visual approach of events applied to maths, which could be quite useful for some (and probably a good deal faster than typing formulas every time). Doing a spawn object and knowing it will have a random rotation, size, opacity and promptly move for an amount of time and then fade out seems like a good approach without needing to add variables, extra events, accessing behaviors, etc. Being able to create an "independent" self-sufficient object that just works seems like a fairly "Construct" thing to me.
I realize it's once again a question of approach - have seen it before oh so many times. But thank you sincerely for taking the time to reply and state your stance on something like it.