There's CUDA and opencl recommended for general purpose computation on GPU. The drawback is they typically need compute kernels which are available only on high end GPUs. Libgpcogl abuses the fragment shader mechanism for computation instead. This has the advantage that any GPU can do it, even old and low end ones.
The advantage is lower hardware/driver requirements and higher portability. The drawback is the uglier OpenGL interfacing (inside the lib), probably lower performance because of having to work around layers designed for 3d graphics and some limitations coming from the fact the GPU thinks it is drawing pixels.
The target for libgpcogl is typical "consumer applications" having to run on random desktop computers, maybe on dedicated servers or even a small cluster of servers. It is well suited for the situation where the given application has a computational task where using any GPU could result in a major speedup but it is not as much mission critical that an expensive GPU is purchased especially for this task.
It's especially reasonable when the given computer is not really dedicated to this one task, but is used as a generic desktop or server that's running the computational task in part time.
This lib is probably suboptimal for more dedicated tasks, where a computer (typically server) is built to mainly perform only that one task, e.g. bitcoin mining or serving AI, 24/7. In such cases computation performance vs. power consumption ratio is critical, in which case investing in a GPU designed for generic purpose computations and using an appropriate API (e.g. CUDA, opencl) pays off.
Since libgpcogl tries to be portable among different GPUs, it aims for a common denomiator. This means it can not exploit special extras of a given GPU and typically won't be able to extract 100% performance.
Libgpcogl requires desktop OpenGL 3.1 or higher. It also works with OpenGL 3.0 if the rectangle array extension is present. The lowest GLSL version required is #version 130. These standards date back to 2009 November so cards and drivers produced from the early 2010s should generally work with libgpcogl.
OpenGL ES (GLES) is not supported because it is not guaranteed to have rectangle textures which are essential for the lib.
There is no Vulkan support - Vulkan is too new, too few hadrware supports it, especially from the low end or middle range cards the lib targets.
Only a few common data types (float32 and (un)signed int32) are supported; in theory the lib could support more exotic types like 16 bit ints or half floats, but for the sake of simplicity for the current versions it sticks to 32 bits.