With some simulators, you can script-design the I/O, allowing you to debug the I/O in the simulator.

Having real hardware transfers often kills the debug session directly you hit a breakpoint.

Having simulated I/O means you can take a phone call or switch to other source files and take a closer look at data structures etc while figuring out why simulation fails. Obviously, when I do have real hardware, I would start debugging with the real hardware and only switch down to the simulator if I do need to freeze time.

I don't know if you have tried out the scripting language in the Keil simulator. It is quite nice to use.

So no - the simulation is not worthless for debugging I/O problems. It is a different way of debugging I/O that allows you to use other approach. And I often have simulator code written for I/O simulation long before I have first hw prototype so if I do see real problems with the physical hardware, I can go back to the simulator and see if I can modify the I/O simulation to trig the same problems.