Everytime when I see post like that instantly I'm seeing UE4 blueprints in my head. There is really no point to compare epic to scirra (hundreds of hands vs only few couples) but they have nice system with object blueprints and level blueprints working together.
So maybe this is a thing worth do some tests. Not only to make events more clear - you could have object events on objects only and everything else on level events, but maybe level events could work on 1 cpu and objects on another etc.
And on the other side this kind of system have more sense, at least from my point of view. Even for beginners who tends to make one huge and messy event sheet with everything on it. "Double click on sprite to add some logic to it" feels more natural and most engines are using similar approach. You don't make just one text file full of code for entire game to compile.
But I'm just a user, so I'm just saying what I see xD
Maybe that makes sense, given that Blueprints also evolved like that. The Kismet predecessor only had global level scripts, then the system was extended to be (optionally) object oriented with Blueprint.
Maybe it wouldn't need anything complex even to make this useful. Simply being able to assign event sheets to objects could be helpful already, with no major difference other than defaulting to "pick all instances of this object" for all events in such a sheet. Allow sheets to be assigned to more than one object and you even have reusable sheets that work on different object types, which would not be far off from adding behaviours. Perhaps also add an abstract object type to hold data and/or events only, so Sprite doesn't have to be abused for this.
Another thing I'd like to see is an evolution of the Function object, perhaps by creating a function behaviour that can be assigned to objects to create "member" functions. So we could do something like MyObject.Function.Call("MyFunction"), which triggers MyObject.Function.OnFunction.
The only issue with that (and Function in general IMO) is that the syntax is really cumbersome, so why not make Function a first class feature of the editor, with its methods exposed by each object? Then you could just write Call("MyFunction") or MyObject.Call("MyFunction") instead of Function.Call("MyFunction") and MyObject.Function.Call("MyFunction") respectively.
I don't believe those changes would make the editor significantly more complex if you don't need those features, but provide a pretty significant quality of life improvement for more complex development.