This discussion is the reason I hope that C++20 modules gain traction. It is nice to improve myself a a developer (and have a look at different viewpoints), but in the end I don't want to have a tradeoff between code performance and readability.
I would convert my entire codebase to modules in a second if the CMake Support was nicer.
There is no danger of C++20 modules failing to "gain traction". They are already in the Standard. All that is left is to define Standard module names for the Standard library components.
Most likely that will be, simply, "import std" in almost all cases, with no reason for finer granularity.
Of course we will need to update our non-Standard libraries to get the benefits there. That will happen fast once more compilers finish implementing C++20 features.
For me at least, it seems like development on the build system side is very slow. The relevant ticket in the CMake Repository[1] is more than three years old for a critical functionality. There are efforts to make an open interface between Compiler and Build System[2] but these are non-standard and for now it seems like there is not "one good way" to do modules. For example it is possible to do modules with the CMake MSVC Generator[3] but I can't use Ninja when working with MSVC.
One compiler implements module support to the point it's useful, and that compiler targets one operating system.
I don't think it's hard to fathom that C++ modules might not gain traction when there is little indication of adoption in compilers, let alone code based that could benefit them.
They cannot claim Standard conformance without implementing all required features. Furthermore, since Gcc and Clang are also coded on C++, they will not get the benefit of rebuilding the compiler much faster without implementing it.
You are using a snapshot frozen years ago. Surprise, frozen thing is still frozen! You are of course able to build for frozen system with modern compilers (e.g. "dev-toolset-11". If you don't, it is because, and only because, your employer has chosen not to.
CentOS 8 was released (and itself frozen, except security patches) years ago. Current CentOS has been broken loose from RHEL, so if you need bitwise compatibility with RHEL 9, you will need to switch over to building for Rocky or Alma when you move off targeting 7 or 8.
You can build for CentOS 7 in a docker image on your Amazon host, and also run Gdb on your Amazon host, using "target remote" to attach it to a gdbserver on your CentOS 7 target execution environment.
I use sshfs on my host to map a directory on the target, so my builds put binaries over there automatically.
Again, there is no difficulty of any kind in using (say) Gcc-11 to build binaries to run on a stock CentOS 7 target. On CentOS (which user-space environment you would run in a docker image), I think the package you would need is dev-toolset-11. Look it up. (It is possible that is only in CentOS 8, so you might need dev-toolset-9 instead, which would serve.)
I would convert my entire codebase to modules in a second if the CMake Support was nicer.