As Nick T mentioned, TCP/IP is unfiltered and non-deterministic. You said you want to also interface with SPI and UART devices, and previous versions used USB. These are difficult to do in real time, and probably require significant code space.
On the other hand, you want real-time control of your stepper motors, which requires deterministic execution and rapid interrupts but not a lot of program space.
While you said you wanted to avoid using a separate microcontroller because it would complicate things, this is a perfect example of when you need a co-processor, and I believe that it would make things simpler in the end.
You can develop simple stepper motor controller firmware that run on small, cheap microcontrollers. Design (or discover) a protocol that can use a communication bus available in hardware on whatever controller you choose. I'd recommend SPI for this (on a different channel than the device you mentioned in your question; your master should have two SPI peripherals), you don't want to mess with address conflicts given the small number of controllers you'll have. Don't do anything with this controller but run the stepper according to the data it receives over the protocol. You can probably buy something that does this already. The goal is to be able to treat this as a hardware peripheral.
Then, you can develop USB or Ethernet controllers that will plug into these devices. You will have flexibility in the host protocols (Need to use RS485 this time? No problem!), you can use different numbers of motors, and you have greater modularity for designing, testing, debugging, repairing, and replacing. The only reasons I'd try to implement something like this in a single controller would be extreme cost/size restrictions, and/or a lack of hardware modules (like PWM? Did I miss something?) that could do this without interrupting the host processor.
On the PICs with two 32KHz timers (TMR1 and TMR3) my recommendation would be to use one of the timers 'free-running' (never write to it) and use the other to generate wakeup events. If you only have one timer available, getting reliable operation without cumulative errors is going to be very difficult. Different part revisions have different behaviors when it comes to writing timer 1, and so an approach that would work with one revision may be broken by a future revision. What would have been nice would have been if Microchip had allowed the timer to switch between synchronous and asynchronous modes without losing a count (simple to do: instead of using a multiplexer to switch between sync and async mode, add asynchronous set/clear to the synchronizing latch, and when in async mode use those to force the output to follow the input). None of their parts are, so far as I know, documented as doing any such thing. Consequently, I would expect that switching between synchronous and async mode may randomly gain or lose a count.
Best Answer
The SPI module has its own baud rate generator so it does not consume any of the timers. And the baud rate generator is only used in SPI master mode. In slave mode, it is synchronized to the clock of the external master. The only issue you may have with SPI is dealing with the data byte in a timely fasion as it is not possible for a slave to delay SPI like it is with I2C.