It can still have a video display and not be a problem. A modern system isn't going to get bogged down enough even with a very complex display that it will be an issue with processing things in the background. You don't need real time in the strict sense for most home automation problems. You don't want the controller to go of into the ozone for a minute, but that's not going to happen unless it's very badly designed. CQC is constantly doing many things at once, and has no problem doing that on even a low end system, because 90% of what anautomaiton system does is device I/O of some sort another, all of which is done asynchronously on a standard PC (though it may be done in a polling loop on a small controller, which can be a problem.)
Even if you are talking to 25 different devices over various serial, IP, USB, etc... connections, and even if those devices are fairly fast, the data going over that connection is almost always unbelievably slow by the CPU's standards, and it's not much involved anyway. The data is pulled in and sent out via DMA in most cases, and the CPU isn't even involved. The CPU spends the vast bulk of it's time just twiddling its thumbs, even more so in an appliance type system where you strip out a lot of the auto-magical background stuff.
Even on a pretty loaded and active CQC Master Server (which provides centralized services like data storage) that is also running CQCServer (which is where the drivers are loaded), on what would be a bottom end CPU these days (say 1GHz), the CPU load will usually not be more than 3 to 5 percent. It will hit peaks if you change screens on the interface or something, but it still doesn't max out and the peak is short. When there are significant delays, those are almost always caused by the device being controlled, e.g. the digital projector that won't even talk to you for 15 to 20 seconds after you power it on and so forth.
In a system like CQC, which is highly network distributed, there are certainly latencies that get introduced, but they are fairly minimal. Sometimes they are problematic. For instance, someone will say "But I can press this button on my remote control and hold it down and the action repeats really quickly, why can't this expensive system do that?" But it's because the button press on the touch screen packages up some data, posts an async message, which gets picked up by a timer message, which sees a write command, which makes a call to the ORB client, which bundles up the call data and drops it into a queue on the appropriate client connection manager for the target server, which spools it out over the network, where it's picked up by a reader thread on the target server process, which puts it into a queue, where it's pulled out by a worker thread, which unbundles the data, looks up the target remote object, and calls that object with the parameter data, and that target driver object has to wait for the thread that is polling the device to stop, then gets it to do the write of the data to the device, which has to wait for the device to ack that the operation worked ok (or failed.)
Then the whole thing works back the other way to get the acknowledgement back ot the client touch screen that it worked. All that for just one IR or serial or IP event to be sent out to a device. It's actually amazingly fast considering what all is going on, but it can make highly interactive operations, like dragging a volume slider with your finger, kind of spongey, and certainly less immediate than just pressing a button on a 'send and pray' type IR remote.
In almost all cases the primary delay problem is the device itself. And this relates back to the original #1 problem. If you have a device that must be polled for data, and that's very common, in order to have low latency you have to poll it rapidly. But if you poll it rapidly, that means that the connection to the device is in use a greater and greater percentage of the time. This means that, when the user presses that button and wants to send out something, the odds go up that the driver will be in the process of polling the device at that time, and the incoming thread that processes the write has to wait for that to complete since it cannot talk out the port at the same time. If the device responds very fast and the link is fast, it's not a problem. If you poll every 250ms, and the round trip is 50ms, that's not too bad. But if the round trip is 1 second, then there' always the chance that you'll want to cause a write command at just the point when it starts the poll cycle and the write gets delayed by a second.