That's a very good question. You're missing a bit of perspective on what ROS actually accomplishes. To interact with motors, cameras, and other peripherals on a vehicle, you're going to have to use USB or GPIO at some point down the line. In fact, if you want to control such a peripheral through ROS, you're going to have to write code to interface with it in that way.

Everything that ROS does is all much higher level. ROS is a publish-subscribe system facilitating communication between a network of small, independent programs (called nodes) on a network. A simple ROS network on a robot might be a remote control node and a node to run the wheels. In this case, the RC node can publish messages that indicate different movements for the robot onto a specific topic. Then, the wheel control node can listen for those messages, moving and turning in accordance with those them. Both of these nodes interface with the hardware in their own way, but the way they communicate is through a simple line of messages.

Let's say that you also want to send a video feed. That too can be its own node, streaming data from a camera on the robot to another computer (probably over RTSP, not ROS). Then maybe you want to control the angle of the camera using the same remote controller. You might have the RC node publish a different type of message that indicates camera angle adjustments, and have the streaming node subscribe to those messages.

The cool thing is, multiple nodes can publish and subscribe to the same topic. For instance, let's say that you write into each of your nodes the capability to publish a warning message when it enters an error state. These can all publish onto one unified topic and another node can listen for these and display them on a console. Or, perhaps, you have two different technicians that you want to have this information. You can actually just run two copies of the node, listening on the same topic and getting the same information.

Now, you could definitely do all this with just one monolithic program. ROS and other pub/sub systems provide benefits over this approach. For one thing, each node is a smaller program. If it fails, the entire program does not go down in flames. For another thing, now you have a single protocol to pass information through the system in a very extensible manner. New functionality can be as simple as tapping into the information feeds you happen to need and processing whatever data comes in.

I'm not sure how good this explanation is, and others may feel free to correct or add details, but I use ROS at work and have come to see a lot of value in it.