devtoolset is called gcc-toolset in RHEL8.

The following commands worked for me:

microdnf install -y gcc-toolset-12
scl enable gcc-toolset-12 bash
gcc --version
# gcc (GCC) 12.1.1 20220628 (Red Hat 12.1.1-3)

So, two things...

One: Certificate based repositories are a function of "subscription_manager" while "RHN Classic" is the traditional RHN. First you need to know which type your system is using. If it's "certificate-based repositories" (aka subscription_manager) then you'll see the file /etc/yum.repos.d/redhat.repo with content like:

[rhel-6-server-rpms]
name = Red Hat Enterprise Linux 6 Server (RPMs)
baseurl = https://cdn.redhat.com/content/rhel/server/6/$releasever/$basearch/os
enabled = 0
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta,file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
sslverify = 1
sslcacert = /etc/rhsm/ca/redhat-uep.pem
sslclientkey = /etc/pki/entitlement/1111111111111111111-key.pem
sslclientcert = /etc/pki/entitlement/1111111111111111111.pem
metadata_expire = 86400

If this is the case you're likely using subscription_manager, if on the other hand you have a file located at: /etc/sysconfig/rhn/systemid then the system has been registered via "RHN Classic". Regardless, whichever method you have used, the other one should be turned off. This can be done by configuring the corresponding plugin's config located in: /etc/yum/pluginconf.d/

For "RHN Classic" this will be the file "rhnplugin.conf" and for "subscription_manager" it will be "subscription-manager.conf". These are enabled/disabled by setting the boolean value "enabled=[0|1]" in the corresponding configuration file. If you have neither of these configurations then your system is not registered via RHN/subscription_manager and despite having local administration privileges you should contact your sysadmin who is in control of your RHN entitlements. If you are registered, let's keep going.

Once you have disabled the plugin you have chosen not to use, verify that you can see the groups available and no error messages via the command:

yum grouplist

or, even better:

yum grouplist | grep -i development 

this should yield output similar to:

redbeard@yum01 [~]# yum grouplist | grep -i development
   Additional Development
   Desktop Platform Development
   Development tools
   Server Platform Development

You'll notice that the name "Development tools" has a lowercase initial character in the second word. I did validate that this should work regardless of case.

redbeard@yum01 [~]# sudo yum groupinstall "Development Tools"
Loaded plugins: product-id, security, subscription-manager
This system is receiving updates from Red Hat Subscription Management.
Setting up Group Process
Package 1:pkgconfig-0.23-9.1.el6.x86_64 already installed and latest version
Package binutils-2.20.51.0.2-5.36.el6.x86_64 already installed and latest version
Package elfutils-0.152-1.el6.x86_64 already installed and latest version
Resolving Dependencies
--> Running transaction check
---> Package autoconf.noarch 0:2.63-5.1.el6 will be installed
---> Package automake.noarch 0:1.11.1-4.el6 will be installed
---> Package bison.x86_64 0:2.4.1-5.el6 will be installed
---> Package byacc.x86_64 0:1.9.20070509-7.el6 will be installed
---> Package cscope.x86_64 0:15.6-6.el6 will be installed
---> Package ctags.x86_64 0:5.8-2.el6 will be installed
....

Group install just installs some group of packages (= all packages in a group). This can be useful when you want to install gnome desktop, and instead of typing yum install gnome-session nautilus gdm <and many more> you can just run something like yum groupinstall "GNOME desktop". For servers I don't see any reason to use groupinstall and don't recommend it: don't install anything you don't really need. Use yum install <package> to install something you really want.

And, to check what's being installed with groupinstall use groupinfo: yum groupinfo "Development Libraries". To get list of all available groups run yum grouplist.