gcc is still included in base on amd64 for now, but the default system compiler on amd64 (and i386) has been clang since OpenBSD 6.2. If you use the /usr/bin/{cc,c++} symlinks, you get clang. Nothing uses the base-gcc now, but it being kept as a convenience for porters to test with as some architectures have yet to switch to clang.
The change mentioned is only that gcc4 (base-gcc) will no longer been installed alongside clang on i386 and armv7. If you need gcc, you can install ports gcc 8.3.0 from packages.
Do you know what sparked the change that uprooted gcc's "dominance"? I know the GNU libc added a lot of "opinionated" pieces, but I thought that was mainly opt-in. I'm curious why gcc "lost its crown" and clang gained all of the attention.
I don't follow, I'm sorry. OpenBSD has never used GNU libc. The BSD projects have long developed their own C libraries.
The clang compiler is a part of the LLVM collection, it is not derived from gcc at all.
As for GCC, The GNU project changed the license for their compiler sometime after the 4.2.1 release to the GPLv3. Meanwhile, up until the Clang 9.0.0 release, Clang was developed under a permissive license (NCSA). We're facing a similar problem now with LLVM/CLang, with their re-licencing to the non-permissive Apache 2.0 license.
clang doesn't derive from gcc in any meaningful way (it does implement some gcc extensions though). There's two main reasons that LLVM and clang really got a lot of wind behind it, and that's largely Apple and the GPLv3. Apple decided that they wanted more control over their objective c and other compiler infrastructure so they threw resources at the burgeoning LLVM to start trying to get it competitive. That was driven both by the difficulty of maintaining a GCC frontend & port, and also by the license change to GPLv3 that happened. That's also why the *BSD and other projects started throwing support behind LLVM and clang, because the GPLv3 put further restrictions on them that they didn't agree with which is also why gcc 4 is the latest version of gcc to ship by default with openbsd. That's also what has kept such an old version of bash on macos/osx. Clang's more favorable (for a distributor) licensing makes it easier to deal with for shipping by default.
That's also not to discount some of the other efforts that clang made to make developer's lives easier with better error messages and for a decent amount of time, better static analysis tools (they're fairly comprable now). Those definitely helped but I don't believe that they drove nearly the same amount of time and resources compared to the above points.
EDIT: missed the bit about the libc stuff in parent comment
GNU libc and gcc are completely separate. As the sibling stated, the BSDs and other systems didn't use them and gcc doesn't require or directly use it either. There is a libgcc that gcc usually needs, that provides a bunch of boilerplate/other stuff to bring up the executable but that isn't part of either the C language or the C library. It's things like a definition of the _start() entrypoint and things to handle setting up static variables during initialization and that kind of thing. It's also got a GPL exception specifically in it's license to avoid conflicts with having to link with it. It is possible to build things with gcc without linking to that library, but you end up having to provide it all yourself. This is how gcc usually gets used on smaller embedded systems that don't need all the things it provides otherwise.
clang did not derive form gcc. apple gave it funding because they don't like the GPL. and then everyone else who had distaste for the GPL (BSD people) also switched over when clang/llvm were up to par.
The change mentioned is only that gcc4 (base-gcc) will no longer been installed alongside clang on i386 and armv7. If you need gcc, you can install ports gcc 8.3.0 from packages.