I think that your best bet would be a Linux based system. Something like Beagle Board.
Arduinos and their ilk tend to target low cost microcontrollers.
In order to stream video over a wireless connection, you're going to need a fast processor and a fast wireless link. I'd pick an ARM based system, running Linux with WiFi.
Here's an example of what can be done with a BeagleBoard:
http://mechomaniac.com/OpenCVBallTracking
PLC manufacturers would like you to believe that their software is more reliable and more thoroughly tested. My impression is that the core OS components of PLCs are usually quite well designed and tested, but the drivers for external hardware (motion systems and the like) are often libraries hacked together by applications engineers and then passed around the company. The hardware in PLCs is often antiquated-- a lot of them are running old, hot Geode processors.
When you buy a PLC from Allen-Bradley, B&R, Siemens, or any of the other big players, you're mostly paying for support when things go wrong. Their hardware is made with the same manufacturing processes as Arduinos, and there's nothing magical about the real-time operating systems running on PLCs that makes them bug-free. But, I think that support is often worth paying for. If it's a machine that costs the company $1M every day it's not operating, I'd be damn sure that when something went wrong, there was a team of professionals who could help fix it, not just me and Google. For the specific case of light curtains or other safety interlocks, I would want to make sure that the manufacturer had a hefty insurance policy in place, rather than a statement that tries to disclaim all merchantability for any particular purpose.
Even so, if I were designing (for example) a bit of simple pneumatic actuation for some fixture, and I was willing to shoulder the support burden of fixing the machine when it broke (or if I wasn't able to get the resources allocated to pay for the PLC), and safety wasn't an issue, I'd happily use an Arduino.
I'd probably prototype the system with an Arduino and then rewrite the code in pure C once it was working, so that my code was the only code on the microcontroller.
Best Answer
It's perfect. I did this exact thing in my house. I used an MID400 optocoupler to turn the 24VAC present across the terminals of the thermostat (at the furnace end) when the thermostat is NOT calling for heat into a digital high at the Arduino. I'm using an XBee network, but Ethernet (or even a tethered computer) would work just fine, too. It'll work for higher voltages, too.