Why would anyone use gboolean (GLib) instead of bool type?

Uniformity and maintainability. If at a certain point in future a new utf8char type is introduced, it will only be a matter of changing the typedef and recompiling, without having to go through thousands of lines of code to patch every single usage.

Also consider that GLib is meant to work on a wide range of compilers, not all fully compliant with the latest specs. For instance, the availability of bool, wchar_t and fixed-size types cannot be assumed, since they all came with C99 and C11. Furthermore, GLib development began in 1998 (as you can see from the contributors graph), when C99 was still in draft and those features weren't even standard.

Recently discovered it's not just merely about consistency; there is actually caveat involved when dealing with big endian platforms.

On big endian platforms tested so far (PowerPC32, Sparc64, etc) g_option_context_parse() would fail to deal with argument declared with C99 _Bool, as if the relevent options were completely ignored. Switch to gboolean and everything works again. This problem is not present in little endian platforms.

I'm not sure if it's intentional behavior, but the internal parsing of G_OPTION_ARG_NONE type arguments are all handled using gboolean, which is equivalent to native integer in terms of occupied byte size, while _Bool occupies 1 byte only. Probably that explains the problem under big endian environment.