Security is always a balance between ease of use and protection. The most secure system I can imagine is a switched off computer lying in a bank safe. Unfortunately it is also hard to use... Removing compilers or worse restricting them to root on a test or dev system would be nonsense: either you can no longer use it, or you will always log in as root. Things go differently on a production only server where they can normally be removed.
But I can hardly imagine how removing a compiler could secure an Ubuntu server. As for any Debian-like systems, packages are generally installed in binary form, meaning that if an attacker has write access to a folder, he can deposit a program built on his own machine and use it there. And if he has no write access, it will not be able to build an executable file either.
This advice, as many other on security by obfuscation looks like snake oil. That should not cause many harm, but won't really secure anything either... But it is something that is easy to implement in a automatic auditing tools, and can be sold
If you really want to secure a production server, don't focus on compilers, but carefully remove all network (and generic) tools that are not used there, and configure the firewalls to block as many incoming and outgoing connections as possible: if one server was compromised, it will really be harder for the attacker to bounce onto another one. But this cannot be done by an automatic tool because it must be adapted to the actual environment and precise use case of the server. Once this is done, it is possible that the compilers will already have gone away but honestly I would not care. If you want to go one step further, also build a custom kernel containing only drivers used in your environment - ok, you cannot build a kernel if you have removed compilers, but it should be built and tested on the dev or pre-prod system. That way script kiddies trying to use usual kernel addresses won't be able to find them.
TL/DR: my advice is that you do not know what compiler can safely be removed or how you could restrict them to root, do not even try to do it. Just follow the common best practices:
- never use root account for anything that does not require it
- only sudo individual commands or for a short time
- never let a server running as root (except for its initialization time...) and ensure that it leaves all unnecessary privileges before accepting requests
- secure your firewall the best you can and forbid all unnecessary accesses
- do not install unnecessary or non controlled software
And do not trust automatic auditing tools for more than they can do. A serious security audit really costs time and money...