Both OpenGL and SDL are C libraries and expose a C interface to the rest of the world (as pretty much every language out there can interface with C but not necessarily with C++). Thus, they’re restricted to the procedural interface that C gives you and the C way of declaring and using data structures.

Over and above the “interfacing with other languages” aspect that a C interface offers you, C in general tends to be a bit more portable than C++, which in turn makes it easier to get the non-platform dependent part of the code of libraries like these working on another OS or hardware architecture. Pretty much every platform out there has a decent C compiler, but there are still some that have restricted C++ compilers or ones that are just not very good.

While C and C++ are very different languages, they are not “incompatible”, in fact, to a large extent C++ is a superset of C. There are some incompatibilities but not many, so using a C interface from C++ is a very easy thing to do.

I think you are confusing “writing a library” vs. “exposing API to outside”. I don’t know much specifically about the libraries you’ve mentioned (they might be internally written in C), but I know many others, myself included, have written C++ libraries/frameworks which fully utilized all kinds of fancy OOP practices/patterns, but still exposed C-style API to the outside world.

1. C and C++ are not entirely different systems. C++ was built on top of C and a) can easily consume C code and b) is fully capable of providing C-style apis.
2. Advantage of C interface is that it is very easily consumable by the rest of the world. There are interop layers that allow C API to be consumed from just about any language (python, java, c#, php…), where as C++ interface is consumable from….. well, maybe C++ and still not always (different compilers, different versions of the same compiler will cause issues)

In the past, as an experiment in one of the projects at work, i decided to expose “OO” interface from a C++ DLL. In order to hide internal details and avoid a bunch of other things, I almost ended up reinventing Windows COM (component object model). After that project, I realized COM is not as bad as people make it out to be because a) it exposes OOP interfaces, b) takes care of all the issues I ran into and c) is standard enough to be consumable from a number of other languages.

But COM is still not without its baggage. In many cases, regular, plan C-style API is still a much better alternative.

Both OpenGL and SDL are C libraries, not C++ libraries. You can use them from C++, but they’re written in C and have a C API (which is also accessible from other languages; C++ is a pain to access via a FFI). Have a look at Boost for a large array of general-purpose (and some specialized) C++ libraries and SFML for a C++ multimedia library.

Speaking to OpenGL specifically, OpenGL was originally part of a stack of APIs — OpenGL provided a low-level, performance-oriented API, accessible from C (or even Fortran), while OpenInventor provides a high-level object-oriented API, designed to be used from C++, and providing both a high-level scene-graph API, and abstractions for saving/reading scenes to/from files, and GUI integration.

OpenGL ended up going much farther than OpenInventor (it filled a more pressing need, giving video hardware makers something to optimize for, and providing a common low-level API people could target instead of dealing with 3D acceleration hardware directly). But OpenInventor is still out there, and there’s a good open source implementation — Coin3D — with support for Unix/X11, Windows, and MacOS X/Cocoa.

Those libraries are not remotely modern at all. They are C APIs, and bad ones at that. Your premise is flawed.