The important part of the value of TERM is that it matches an entry in the terminfo or termcap databases, and that that entry correctly describes your terminal.
You cannot reasonably go telling softwares that your terminal is XTerm, when it blatantly is not. And it is an outright error to think that other terminal emulators use all the same input/output control sequences as XTerm or provide all the same functionality.
-256color is simply a part of a name, it has no inherent meaning to most softwares (albeit that a very few do look for feature suffixes). It (primarily) only has meaning to human beings, as it is human beings that group the entries in the terminfo/termcap databases into families by their names. The feature suffixes in terminal type names are primary for humans, not for softwares.
The thing that has meaning to softwares is whether the record in the database that is so named says that the terminal supports 256 colours, and provides the control sequences for using them on that type of terminal.
That said, emacs does do its own thing, and does not simply rely upon the terminfo/termcap database. For example, it is known that its frame-set-background-mode function matches the value of TERM against ^\\(xterm\\|\\rxvt\\|dtterm\\|eterm\\), which is probably wrong nowadays. The correct approach here is to fix emacs so that, at last, it properly recognizes the st-256color terminal type (and putty-256color, vte-256color, and others).
Further reading
(add-to-list 'term-file-aliases '("st-256color" . "xterm-256color")). However, this is killing my emacs startup time so I was curious if taking a sledgehammer to the problem would cause issues... and it sounds like it probably would! – Brian Fitzpatrick Apr 25 '19 at 18:13