I wonder if it's cheating for a robot to have its "brains" in the PC, with some kind of wireless connection to the servos. Perhaps that's not any more cost effective.

Using a PC is definitely not cheating and can be much cheaper if you use an existing PC. The down side is that an existing PC will usually have a real time unfriendly OS like Windows or standard Linux which makes it difficult to use cheaper sensors. Cheap simple sensors require very fast response time because a lot of the work is done in software. Workstation type operating systems think nothing of turning off the outside world for major fractions of a second, fast for a human but slow for reacting to physical events that a robot sees. This is one of those design goal problems with workstations. Just like workstation tools like Python assume that plenty of disk and RAM is available, workstation OS' assume that they can hog time at human perception rates. A lot of work has been done in the last couple of years to make Linux compatible with real-time requirements, for example RTLinux, which directly address the low level robotics response time requirements. This will make Linux the OS of choice in coming years, especially as the cost of Linux capable platforms comes down. We are sitting at the cusp. John Pennington's work is addressing this.

Wireless Ethernet has certainly come down in price.

True but unfortunately not in power consumption. Power is a big issue for robots since they have to carry their power supply. The main reason you don't want to use a PC with cable is that it limits the robots mobility. However many interesting robotics applications don't require mobility. It is very common to do both, use a workstation for development and an autonomous computer in the application. This is again where Jonathan's work is interesting. Things like Pippy run on many platforms. Another interesting application of robotics hardware is physics experiments. Some robot sensors can detect wheel angle. This allows doing things like putting a robot on a ramp, letting it roll and measuring the wheel angle with time. From this data and measured wheel size speed and acceleration with time can be calculated. From there the acceleration due to gravity can be measured. A little vector calculation with ramp angle and the force of gravity is measured. Data reduction can me done in Python on the workstation although I prefer a spreadsheet for this. When I do data reduction in a computer language I copy and paste the results into the program using it to initialize an array. LEGO Mindstorms itself might be responsive enough to do this experiment, especially with a shallow ramp to slow things down. Robots and their gears and pulleys are good platforms for learming about mechanical advantage and simple machines. A vital part of robotics development is measuring the behavior of the robot and its sensors. This process of analyzing real world attributes should be a good teaching tool. Simpler measurements can be factored into a lesson plan. Things like how close does the light sensor have to be before it sees an object (by reflection. LEGO light sensors have built-in light source.) Are different surfaces detected at different distances, different colors, shiny vs. flat. How does this impact the robots algorithm. This interactive process of quantifying and understanding physical properties is obviously quite valuable. A robotics professional has to understand computers and software, electronics and mechanical engineering, leverage and transfer of energy, noise, friction losses and efficiency, algorithm development, sensors and actuators, working within external constraints etc. There is rich ground here for all kinds of learning experiences. If Jonathan can make the connection between Python and robots Python can have a major role to play.