Re (1), The CRT non-standard functions serve many areas, many of which are not available for the Win32 APIs; e.g. the debug heap, but the important thing is consistency. This will reduce bugs and maintenance of course. Sometimes, you have to use CRT functions; for example if you're creating new threads and expecting to call CRT functions within the thread methods, then use _beingthread() or _beginthreadex() instead of Win32's CreateThread(). If you don't use _beginthread*(), then there could some memory leaks.
Another example, is the environment variables functions. To make sure your environment variables are correctly read/updated, then either use the CRT functions exclusively or the Win32 API ones. Finally, the CRT functions have been designed to abstract away many of the complexities of the Win32 APIs, so you may find them easier to use. _exec* functions are much easier to use than CreateProcess for example.
Re (2), like you've mentioned yourself, as with the whole product, O/S version support for the new CRT is not yet finalized, but I will try to get more details for you here.
Re (2), this Connect bug talks about the same issue:
"This [No XP support] behavior is by design in MFC and CRT for Visual Studio vNext. The minimum supported operating systems are Windows Server 2008 SP2 and Windows Vista. Windows XP is not a supported operating system for the release (design-time or run-time)."
The release mentioned is "Developer Preview".
There's a workaround already described there as well, which is use the multi-targeting feature. If you have Visual Studio v10 and vNext installed on the same box, you can target v10 compiler toolset and libs inside Visual Studio vNext. The limitation of course, you'll not benefit from improvements to the CRT or compiler or other libs improvements/bug fixes.