Lua has worked well for our team. I found that our students learned Lua much faster than C/C++ and that it allowed us to make changes more quickly and easily than C/C++.
Our major snag was runtime errors during development. Since Lua doesn’t get compiled, errors like misspelled variable names don’t get caught until they are deployed on the robot. While we did develop some tools internally to catch the vast majority of these problems before deployment, this may be a drawback for some. However, we never had a runtime error occur during a match: it’s all just a matter of proper, thorough testing, which is what teams should be doing anyway.
WPILib updates were a non-issue, as SWIG happily regenerated new bindings from the header files.
Our code design greatly benefited from some of Lua’s features, such as anonymous functions. Using anonymous functions and tables, we were able to make control changes as easy as remapping buttons on a video game: each joystick button/axis was directly mapped to a function that was called so that the control logic is separate from operational logic.
All in all, I feel that Lua is a viable option for teams, and I know we will be using it next year.