It sounds like minimizing the use of sensors and advanced automation techniques is a good fit for your team based on its resources. In general I applaud teams for being pragmatic about what is within their means.
As awesome as they are, the problem with sensors, automation, feedback control, and advanced autonomy is that there is a HUGE learning curve that you must conquer before you come up with even pretty basic functionality (ex. how many teams in FIRST can program their robot to accurately and repeatably drive a non straight line path?). Adding a sensor or automated routine to your robot also causes the number of potential failure points to increase exponentially, and in the 6-week-build world of FRC you often find a lot of heavily automated robots having teething problems as they discover these failure points.
FRC is very heavy on mechanics. While true "powerhouse" robots are a result of mastery of all aspects of engineering, many well-built robots with bare-bones code have won Regionals. Comparatively few kitbots with world-class code have done the same.
Mechanical disciplines, in general, are more tangible and are more quickly grasped by students. They have also been around for thousands of years longer than software engineering and we have become pretty good at formalizing them. Even in the microcosm of FRC, we had COTS gearboxes available to us long before COTS computer vision software (since the CMUcam was basically a closed system, I do not include it in this self-indulgent lamentation about the short changing of software in FRC
).
FRC games usually have some sort of incentive for automation (vision targets, randomization, additional game pieces during autonomous mode, etc.), but clever teams often find low-tech solutions to these problems that work just as well during teleoperation (best example I can think of is the "photon cannon"). Balancing the "need" for sensors and automation against the fact that many teams are deficient in these areas is (I would imagine) a real challenge for the GDC.