Not really? XeLaTeX is "the LaTeX API (because it's an API built to be run by a TeX engine. LaTeX is built on TeX the same way jQuery is built on JavaScript) run using XeTeX" (the natively-unicode-aware TeX engine).
So if your publisher has a LaTeX template, that's pretty much guaranteed to work just fine when you \usepackage it in XeLaTeX context. Needless to say, except it really does need to be said, that also means full Unicode Maths support (through \setmathfont{A normal font name} without needing TeX metrics nonsense because it's 2017) for any OpenType font with maths support (Cambria Math, XITS Math, etc. etc.)
I was thinking that if you draft a document in XeLaTeX/LuaLaTeX, including a template, then if you don't bother to really learn how font handling with XeTeX/LuaTeX works, you might end up with some fontspec or polyglossia line in your code, etc., and there might be problems with a template that does things oldstyle.
Another point is that some packages haven't been updated for Unicode, algorithms2e being one popular package that's still Latin-1, IIRC.
Then if your code will be compiled from source by someone using pdfLaTeX, your Unicode characters will cause problems.
Hence why I say that it's probably more pain than it's worth, since there are still things you need to understand to avoid incompatibility. I think a more proper analogy would be C and C++, since while XeTeX/LuaTeX is mostly LaTeX compatible, 1) you risk running into sinister incompatibilities and 2) typical XeTeX/LuaTeX code is different from, and incompatible with typical LaTeX code.
So if your publisher has a LaTeX template, that's pretty much guaranteed to work just fine when you \usepackage it in XeLaTeX context. Needless to say, except it really does need to be said, that also means full Unicode Maths support (through \setmathfont{A normal font name} without needing TeX metrics nonsense because it's 2017) for any OpenType font with maths support (Cambria Math, XITS Math, etc. etc.)