UI is hard. I'm not saying it can't be improved, but I can think of several difficult problems with every proposal here.
Any form of typing in conditions and actions needs to be able to enter parameters as well. (If not you just have to bring up the parameters dialog again which kind of defeats the point of typing in events.) So typing in "Sprite overlaps Family at offset (3, 5)" requires having a way to unambiguously parse out the parameters "Family", 3 and 5 from the entered string. This is only semi-possible. It's not a strict enough system to remove ambiguities. For example imagine two conditions with these names:
Sprite: overlaps [object]
Sprite: overlaps solid
If you type in "Sprite: overlaps s", which condition are you typing in: "overlaps solid" or "overlaps [object]" with an object name beginning with "s"? I am sure there will be many examples like that, especially when including translations, which could make it pretty frustrating to use. There are also extraordinarily tricky parsing problems in cases such as this:
Sprite overlaps Family at offset (Function.call("calc", 3, 5), max(3, 5))
where the commas in the function call have to be identified as different to the comma from the condition description text, and similarly with the parentheses. Again I am sure in some cases this will be impossible to resolve unambiguously depending on the condition description text. So this could end up being a feature that sounds nice to have, but actually turns out being difficult to use and semi-impossible to implement. It could be fixed by using special tags to identify parameters, e.g.
Sprite overlaps ${Family} at offset (${Function.call("calc", 3, 5)}, ${max(3, 5)})
...but it seems to me that's a pretty ugly thing to have to type in, and is beginning to look like a weird mishmash of natural language and a pseudo-programming language! You could remove the natural language part and go full syntax with something like this:
Condition(Sprite.Overlaps, Family, 3, 5)
...but now you're in to the realm of inventing your own custom programming language, and you may as well go with a mature industry-standard like Javascript, which contradicts the "no programming" message we have been focusing on for years.
The alternative UI design is interesting. I could nit pick about scalability for large projects and lacking search boxes, but I think the main problem is information overload. It shows everything at once and has so many sections it's a sort of god-dialog that tries to encompass everything. I think good UI design is as simple as possible. Also IMO the biggest flaw is how it swaps the conditions list for expressions - the dialog is already so packed that there is no more room, so it recycles the middle pane for the fourth expressions panel. Lots of beginners get confused enough by the difference between conditions and actions, and then swapping conditions for expressions - which are very different things - will probably trip up a significant number of beginners in to being unable to figure out WTF is going on.
I'd point out the current system of using three separate "pages" with one floating dialog for the expressions list keeps everything simple by splitting the steps, and should be fully navigable by keyboard shortcuts. (I think I remember someone saying they can more or less "type in events" just by getting really good with the keyboard shortcuts.) There's also the back and next buttons to easily switch between conditions and objects while preserving as much state as possible. So I think it's closer to keyboard-navigable than some people think. Radical departures from this really need to be thought about very carefully. I'd add that I don't think I've seen anyone complain about the current system for a long time, so it seems to be working well.