First of all, OpenGL does NOT do any color conversion by default.
Let's start from the smallest configuration, consisting of an Input Image, Window Buffer (rendered by OpenGL) and a Monitor. Each might be defined by different color space, but in simplest case it will look like that:
[RGB image|sRGB] -> [OpenGL Window Buffer|sRGB] -> [Monitor|sRGB]
By default, monitors are configured to use an sRGB preset, even the ones supporting a wider color range, to avoid incorrect color output. Rendering into OpenGL Window Buffer by default doesn't perform any color conversion, so that if input image was in sRGB colorspace it will remain the same in OpenGL Window Buffer. OS Composer normally just copies OpenGL Window Buffer onto the screen - no color conversion is implied at this step too. So basically all steps just pass-through input image and you see result as expected if it was in sRGB colorspace.
Now consider another scenario: you are applying Input Image for texture-mapping onto 3D object with lighting enabled. Lighting equation makes sense only in linear RGB colorspaces, so that without extra configuration OpenGL will basically take non-linear sRGB image values, pass them as parameters to shading equations unmodified and write result into OpenGL Window Buffer, which will be passed-through to Monitor configured to sRGB colorspace. The result will be affordable, but physically incorrect.
To solve the problem with incorrect lighting, OpenGL has introduced sRGB-awareness features, so that user may say explicitly if Input Image is in sRGB or linear RGB colorspace and if result of GLSL program color values should be implicitly converted from linear RGB colorspace into non-linear sRGB colorspace. So that:
[GLSL Texture Input|sRGB -> linear RGB implicit conversion] ->
-> [GLSL Lighting Equation|linear RGB] ->
-> [GLSL output|linear RGB -> sRGB implicit conversion]
The steps with implicit conversion will be done ONLY if OpenGL has been explicitly configured in that way by using GL_SRGB8_ALPHA8 texture format and by using GL_FRAMEBUFFER_SRGB while rendering into offscreen or Window Buffer. The whole conception might be tricky to understand and even trickier to implement.
Note that in this context "linear RGB" actually means linearized sRGB colorspace, as it is often omitted what linear RGB actual means. This is because for color math (lighting and other) it is important only that RGB values are linear on input and output in any linear colorspace, but when speaking about implicit sRGB -> linear RGB and linear RGB -> sRGB conversion - these clearly rely on conversion of RGB values defined by sRGB and OpenGL specifications. In reality, there are more linear RGB colorspaces which do not represent sRGB colorspace.
Now consider that your Input Image is not in sRGB colorspace, but using some another RGB color profile. OpenGL doesn't give much other texture formats save linear RGB and sRGB, so that a proper conversion of such image into sRGB colorspace should be done by image reader or via special GLSL program performing colorspace conversion on-the-fly.
Now consider a Monitor being configured to non-sRGB profile like AdobeRGB. In this case passing-through sRGB image to OpenGL window will produce distorted colors. By letting Windows know that your monitor in another color profile you will help some applications like Photoshop to convert colors properly, but OpenGL knows nothing about these color profiles configured in Windows! It is an application that is responsible to apply color profile information to perform a proper color transformation (via special GLSL programs or by other means). By working with an Input Image in non-sRGB colorspace application will have also an alternative to perform non-sRGB -> sRGB -> another non-sRGB color conversion or to implement GLSL program which will perform color conversion without proxy sRGB (or via proxy XYZ) directly to target colorspace to avoid losses of color precision information due to transient conversions.
Supporting arbitrary color profiles in OpenGL viewer not designed to be an image viewer might involve too much complexity. Some systems, however, define several standard color spaces to perform implicit conversion by system composer - which is much more reliable than supporting arbitrary color profiles with their special lookup tables and formulas.
For instance, macOS defines NSWindow::setColorSpace property which allows application to specify explicitly in which colorspace Window Buffer is filled in, so that system itself performs necessary conversion to actual Monitor color profile. Android system defines a similar interface for supporting a new P3 Display color profile with an extended color range compared to the old sRGB color profile. This implies, however, that OpenGL renderer actually knows how to output result in this specific colorspace - which is another topic (there are also a set of extra OpenGL extensions helping developers in this direction)... So far I haven't heard about a similar API in Windows, but I might be missed something.
