Multiple threads are indeed the recommended way of doing what you want. Do not confuse that with having multiple
IOIOThreads, which is
not what you want.
A thread is automatically created by the IOIO framework for every possible IOIO connection. This is some internal bookkeeping that is not immediately relevant for you, but in short, this will be the thread on which your setup() / loop() / disconnected() methods will run, should a session to the IOIO be established on that particular possible connection. The deprecated stuff is indeed, er, deprecated and I would strongly recommend that you don't use it.
From the setup() method (which is called once you have a live IOIO session) you can do whatever you want. Specifically, you can create multiple Threads (just normal Java threads), passing them the IOIO instance of some more specific interfaces or whatever and do real work. The IOIO API is completely thread-safe, you don't need to worry about synchronizing access yourself.
For clean closing, make sure that all these threads exit quickly after the IOIO connection drops (e.g. in response to ConnectionLostException), and that your disconnect() method join()s all threads, i.e. waits for them to exit.
That's pretty much it. The IOIO codebase contains an app called IOIOTorture test which uses a similar pattern. In that case, it is exercising all the peripherals concurrently to validate the IOIO software / firmware under concurrent load.