You've got two different issues here:
- java.io vs. java.nio
- TCP vs. UDP

These two have nothing to do with each other.

You have articulated the advantages of NIO over the older style quite well.
You've convinced me that the NIO channels will let your server work faster and
scale better.

Since you're familiar with NIO and have seen its advantages already, there
isn't any downside to it in a potential UDP-based solution, is there?

You wouldn't necessarily use UDP in addition to TCP; you might use it instead
of TCP.

TCP is reliable; UDP isn't.  In fast-moving 3D games reliability tends to be
less important than latency.  If the infrastructure is stable and fast enough,
then UDP packets will just be handled if and as they arrive at the destination
clients.  The downside is you have to handle ordering yourself.  Late packets
might confuse the client if it doesn't have explicit protocols to handle them.
 (Typical - insert if you haven't passed its timestamp yet, discard else.)

There's a nice short summary entitled "TCP vs. UDP" at
<http://www.skullbox.net/tcpudp.php>
.  It was my first google hit on a search for that phrase.

In a game, as the client processes the packets it's received, things like the
position of the Garzon Destroyer can be updated in a leap if you've missed a
few packets.  Maybe some of your torpedo shots will miss that should have hit,
or vice versa.  As your thumbs wear out manipulating your console, you will
never notice.  The client just shrugs its metaphorical shoulders and does the
best it can with the data it does receive.

A mixed architecture will have two communications channels - a TCP one for
critical data like meta-commands and a UDP one for, say, audio/video streams.

Whether UDP is faster depends on how much processing you have to do to handle
things that TCP would have done for you at a lower level, like ordering your
incoming packets.  If you end up patching every hole left by TCP's absence,
you might as well let TCP do it for you.

Whether faster matters depends on whether the TCP solution is fast enough.

Take heed of the OSI model of network protocol design.
<http://en.wikipedia.org/wiki/OSI_model>

Also, remember that premature optimization is the root of all evil.  Be very,
very certain that what you optimize is actually the bottleneck.  That means
test and measure.  Starting with your existing architecture as the baseline.

Summary: stick with NIO, now that you have it under your belt anyway.  TCP
might be fast enough, and might not even be your bottleneck if you even have
one, which you won't know until you test and measure.