Decisions like this usually hinge upon catering to concerns about ease of maintenance and safety, albeit that security, mentioned in other answers, is a factor. Some system administrators don't want odd undocumented personal customizations for the superuser's interactive environment. They want things to behave in the standard, documented, ways; with no nasty surprises. They moreover want to avoid having to re-apply personal customizations after fresh installations, system upgrades, and so forth.
In the case of
vi, aliasing it to
vim potentially brings up a different program on CentOS,
/usr/bin/vim instead of
/bin/vi. The former is an optional "enhanced VIM" that could be present, with all sorts of features compiled in, whereas the latter is "tiny VIM" with very few optional features enabled. (Ubuntu has a similar idea.) People generally want the
vi command to behave as the standard
vi command, especially when doing stuff as the superuser. They don't want some enhanced whiz-bang feature or plug-in altering stuff in surprising ways; or, worse, breaking in rescue or emergency modes. They don't want all of the
vi reference doco that someone doing critical work as the superuser consults, to be drastically erroneous because of such things.
This means invoking
vi when the adminstrator asks for
Put another way: Whereas you have come to take all sorts of VIM customizations and extensions for granted, what some other people tend to take for granted is that the superuser account does not have such customizations and extensions. They build that assumption into WWW pages, Q&A answers, and books that they write. They form habits and carry knowledge from one system to the next of what they'll get when the superuser runs
vi. (And sometimes this is that it has VIMisms, ironically. One of the things that people have to learn going from a Linux operating system to FreeBSD is that
vi is nvi and not any flavour of VIM at all.)
Moreover: They want not to have to remember to carry
/root/.gvimrc over hard disc changes, system reinstallations, and the like; in addition to the system-wide configuration files.
Another example of this thinking in action is the
toor account on FreeBSD. It's the superuser, but with a Bourne-like shell (the Almquist shell, in fact). The
root account has the TENEX C shell, and because there are decades-worth of BSD doco that show the superuser driving the system with the C shell, advice that people give is to leave that as it is, and use
toor for Bourne-like interaction. The C shell is the expected environment when logging in as
root, and if it came up with a Bourne-like shell for a superuser who had (say) a book of C shell instructions for administering FreeBSD, hilarity and indeed potentially disaster would ensue.