@Racer26
Several of the assumptions you make in your post, which parallel some of the decisions made by the Ri3D/BB teams, are not entirely true. While there are a certain degree of truth to them, to see what these builds did and use them as supporting logic for those assumptions is risky.
For instance, "acquire and pass" are not the same thing, nor does either equate directly to being able to score in the one point goal. There are plenty of robots with ground acquisition systems that stow the ball in such a way it is not trivial to pass using the same mechanism. Most of the Ri3D/Build Blitz teams are examples of this, as their eventual storage/launching mechanisms do not permit a clean release of the ball back to the intake mechanism. One can make similar arguments about several of your other points.
More so, you're viewing the conversation backwards. You're using the finished design as evidence of the "optimal strategy," when in reality strategy should drive design. To again use Karthik as an example, look at the
priority list that the Build Blitz team he participated in came up with. Team Copioli's final product doesn't really reflect that list particularly well, as its lowest prority (high goal) is more emphasized than a few of the higher priority items (catching and receiving from the human player). Beyond that, as Karthik has repeatedly pointed out during his presentations, being able to accomplish a task is not as valuable as being able to accomplish a task well. A lot of these 3 day bots ended up being closer to machines that are "5/10" at several different functions, rather than "10/10" at only a few.
I understand the value in showing methods to complete several different game functions, rather than focusing on one or two, during a quick build project. I don't even necessarily disagree with it. But don't attempt to use that to justify their strategy decisions for a team with limited resources.