There are some possible issues with replacing the binaries:
1) They might be re-replaced when you update macOS
2) The binary built by gcc might work differently than one built with clang
3) The interface for the compiler (i.e. command line options as well as other input/output files) might be different, having slightly different syntax, etc.
In general, if you replace the binaries and start building your own software running gcc on the command line - that will work without problem.
The problem is that other programs on your computer might assume that you have clang there. So installers, Xcode, etc. might suffer odd issues. Most probably this is not the case, as Xcode won't run the gcc binary, but for third party projects or older projects - it's hard to know.
Basically: Normally it is not worth the risk to replace the system provided compiler binaries. Just add new binaries for your own compilers at the side (i.e. install them with homebrew or whatever). Then you choose to use those compilers, and everything else will behave like it did before.
Regarding the question you had in an earlier edit of your question questing why Apple "did this": It is infact a common occurence on Unixoid systems to have old names for compilers actually be a front for new compilers. This is usually done to achieve compatibility with old programs. I.e. you had a project that hardcoded "gcc" instead of "cc" as the compiler name, and instead of breaking everyone's build scripts when you replace gcc with clang, you simply add a gcc binary that really runs clang. In most cases that will work producing the outputs that people expected, in some rare cases - it doesn't work, and you would have to install the older (or different) compiler yourself.