If you're going to be hard coding all the strings, there's no real reason to be using anything other than char arrays, is there? I find that the hassle in making code international typically comes from hard-coded values, rather than hard-coded types. A little time spent with the replace function of any text editor can convert code to use TCHAR or wchar_t, but there's no simple way to extract all the hard-coded strings into properties or resources files. So far as I know, at least.
That is true, the toughest part if i18n is collecting all those strings that need to be translated and putting them in text/resource files. However for any strings that don't need translation, or any other hard-coded string, _T() and TCHAR still apply, in case you want to be able to compile your app in both Unicode and ASCII.
Remember, even if you win the rat race, you're still a rat.
You can use non-ASCII characters in regular char strings. It's a little tricky with languages that use multi-byte charsets, since you have to worry about lead/trail bytes, but it's definitely possible.
For the most part you only really NEED Unicode when you're mixing vastly different languages within strings, like russian and chinese.