Let's start with a pick and place robot (a robot arm with a camera and a suction cup that recognizes object in a bin and picks them individually). We can move the robot above the box, and simply wait until we have a captured an image, segmented the objects and computed grasping points and collision free trajectories. We then move to robot to a grasping position, activate the pump and wait until we have grasped something. No need for any real-time in the perception and motion planning part. The motors however have to be controlled in a real-time loop so that they are moving synchronous and immediately stop as soon as a human comes to close to the robot. This part needs to be hard real time.
The whole system could for example be built by a ROS-part that does perception and motion planning and an ABB-Robot (with its own fast(!) realtime controller) that now and then gets new goal poses from the ROS-part and executes them while sending its current configuration back to ROS.
The most important issue here is that we can stop the robot while we are thinking. This does not work if your robot is a drone or a fast moving car. In the drone cases, we need at least a (fast) real time flight controller that keeps the drone flying while we for example send image data to a ground station to decide where to fly next.
In many applications, only small subsystems (mostly the motors) need to be controlled in real-time and the higher level tasks (perception, planning, reasoning, visualization, logging, multi-robot coordination) can take as long as they want. Trying to implement them in real time would be extremely difficult and completely unnecessary.
Another important point about real-time vs non-real-time is its definition.
It does NOT(!) mean that the system can process sensor data very quickly and can therefore react immediately to new sensor data (e.g. child running in front of car). It only means that the system guarantees to perform a computation within a certain time limit. It is perfectly possible that this time limit is in the range of seconds.
For a motor controller (as used above), you need a real-time system that has a guaranteed maximal computation duration in the ms-range. So even if you port ROS to real-time (which is currently done with ROS2), you don't magically are able to control fast moving robots.
So real-time is required, but not sufficient for controlling (the moving parts of) robots.