Gluon is isn't just a game creation program, that is just part of it. It is also a game engine and an online game distribution system with discussion boards, leaderboards, etc. Gluon is also cross-platform, games created for it run not only on windows, but also mac, linux and even some smartphones. It also uses a set of libraries that are shared by games, so individual games are very small and very secure (since they are not given access to anything they shouldn't). Thanks to this, it also means you can embed the game in literally anything. The view of the game you see in the game creator is not a simulation, it is the game's display embedded in the window. There is also a KDE deskto applet that allows you to embed the game in your desktop (works on Linux, but it will work on windows for people using plasma as a desktop). A web browser plugin could also be created to let you play the games in a web browser (although it might take a while to load). Anyone who wanted to could put a game in any other program or form factor they wanted. This is very different than the first link you provided, which as best as I can tell creates stand-alone games for windows only that run only in their own window.
Compared to the second link it is much more flexible, since that is a specialized program for RPGs. Compared to the first link it also seems more flexible. The first link is event-based, which means everything is based around changes in objects, and events are the basic building block you work with. For gluon events are simply one special type of property, of which there can be many others. Furthers, properties belong to specific objects, and objects can have different combinations of properties.
So for instance for construct you have a block object, which other objects can interact with (the objects are all pre-defined, and the only way to change them with programming them as far as I can tell is to add additional interactions). On the other hand gluon would have just a generic object, which would have a block property and other properties that define how other game objects will interact with it. So really objects, interactions, and graphical effects, which are treated separately by construct, are all treated the same in gluon.
So for instance you could create a rocket object, which increases speed and adds some graphics and graphical effects like motion blur, and include it in a car object to give the car a rocket and all the properties associated with it. The rocket would itself by made up of other components like a sprite object and a shader object that gives the motion blur. So each object gives additional properties to any object it is part of. You could also give the rocket to a boat object, or a dog object, and it would give its properties to those objects as well (although the details of how it affects those objects can be tweaked). Things like menus would be created in a similar way to enemies, they would just use a different set of objects. As best as I can tell construct can't do this sort of thing, objects are fixed, they have a specific set of properties and only those properties. You can't mix-and-match properties to create your own object without programming a new objects from scratch.
It is a different, and in my opinion more flexible, design philosophy mirroring. At the most basic level construct is a procedural programming language while gluon is an object-oriented programming language (while also offering support for procedures, of course). This is also a major difference, I believe, with visual basic, which is also procedural if it follows the conventions of other versions of the basic language.
The gluon creator program is also a collaborative program, meaning lots of people around the world can work together on a project, easily communicate which each other, and keep all of their version up-to-date with the changes made by other members of the team without much effort. It also means people can make new objects they create available to the general public and people can easily find and download new objects and games made available by others, rate the objects, comment on them, get connected with people making similar games or games you are interested in, and so on right from within the program.
Also, gluon uses interpreted languages like java for programming done by the game developers, meaning additional functionality does not need to be compiled in, so it can be extended more quickly and more easily (the core libraries are C++, though).
It doesn't look like construct has any capabilities gluon will lack, while gluon looks like it will have many more capabilities and be considerably more flexible in both creating games and in playing and distributing games than construct.
Gluon also has the backing of some major companies, like Nokia, which want to make it easier to distribute content. It is still an open-source project based entirely on open-source libraries, though. I should also add that the libraries are not tied to gluon, they can be and are already being used in other game projects (the audio library, specifically, is already being used in a non-gluon game).