Well, there's a lot of issues I'm seeing here, most of them have nothing to do with your problem itself and more with violating standards like hell.

1. /home is a directory for humans only. System user (that run services) do not own anything in there.
2. steam should be a system user, with its working directory in /var/lib/steam and no group attached (except nogroup).
3. If installed correctly via package manager, steamcmd should reside in /usr/bin or /usr/games (which I despise, but whatever), and mode 755 with owner root:root.

Finally, your problem: You most likely have installed a amd64 system, that in its normal state is not able to execute 32bit ELF files, which you have installed. I don't know how to install a multiarch on a CentOS system (I only have bad experiences with RHEL), but that's what you need to do. And YES, No Such File is exactly the error you get when trying to execute a ELF32 binary from a 64bit system. Been there, done that.

i tried that, and here again:

that is why i did a manual install.

~Travis

If you have to install something without your package manager, there's always /usr/local or /opt ready for you. Thats where the Filesystem Hierarchy Standard proposes to do such installs.

Have you found out how to enable 32bit ELF binaries on your system?

not yet, been busy doing file transfers at the moment. i will get back to this project after lunch (currently 11:38 EST). when i setup the OS, it auto-set the drives so my largest storage is /home. in the past i have created SYM links for storage needy items. not sure if that will suffice here. i will have to check into what amount of storage was allocated for the /usr/local or /opt directories. quick check looks like max of 50GB for the root filesystem, 30GB for swap, and 5.6TB for /home.

~Travis

not sure what i did, but perhaps the correct libraries and binaries were side-loaded in while installing other services earlier. steamcmd.sh is now running, and i am downloading TF2. though this all assumes it runs afterward.

~Travis

it does not run.
the file is available at "/usr/lib64/libstdc++.so.6".

~Travis

I guess your system tries to tell you it couldn't find dedicated_srv.so, which would be a TF2 issue.

Depending on your setup most directories would be on your root partition. I found it helpful to use about 20 GB for /, 1 GB for /boot, 5-10 GB for SWAP and the rest put into /home, and every excess HDD into /srv (after a RAID5 and a LUKS layer has been implemented there - I don't work with less).

currently doing a bottom-up reinstall of Steam and TF2, see if it improves (can't hurt at this point).

my system has 6 drives. first 2 are a RAID1 for the OS root, and the other 4 are a RAID5 for "/home". i don't generally use an encrypted layer, simply because of old habit. if something needs encryption, i encrypt it directly. not like i store any "national security" data. ;)
last time i used an encrypted file system, it made it nearly unusable when i had to move data (physical drives) to a newer server. maybe i am just "old fashioned", as that was back in the early days of encrypted filesystems, i think (late 90s to early 2K). maybe i just implemented it wrong.
in any case, i am still waiting for the game server download to complete, and will report back if the re-download worked.

~Travis

now it runs, up to the point of loading the VPK files, then this:

so i am getting closer, i think.

~Travis

Depending on how you start it, you might run into some Systemd limits, but you can raise them for the service if need be. I have no clue what TF2 needs, but if it's Java, you might try -xmx=8192m on the command line and run it again.

RAID5 generally is better with a 2^n +1 disk setup (reasons being the XOR operation depth), but this is just performance optimization. The encryption layer is a no-brainer - cryptsetup luksFormat /dev/md1 and then decrypt it with cryptsetup luksOpen /dev/md1 md1_crypt, which you can then mount with mount /dev/mapper/md1_crypt /whereever/you/like. Apart from that you don't notice anything. Just don't make the misstake and put it as automount into /etc/fstab, for systemd will halt your system prior to sshd execution, leaving you in need for direct interaction.

It's basics for my apprentices ;)

i start it, currently, with a Bash script.

~Travis

from what i have read, it looks like this is a video ram issue with 32 bit, but as a dedicated server, why should video ram even play a part... very confusing...

~Travis

RAM in general plays a role, at least with Windows it was max 4 GB with 32bit, I think. Not sure if that was also the case with Linux, but I guess so.

yeah, the previous server had 4GB, so it just skirted disaster there. this one has 64GB... bit over 4GB. wonder when the 64 bit TF2 server will come out...

~Travis

I'd give it as much RAM as it can handle, and leave it there for the moment. Use your other 60 GB for other services ;)