tl;dr: geometry_msgs/Twist encodes velocity, not position. There is no quantum of motion (ie: no particular distance is expected per Twist) and any "safety" included by the controller/driver (ie: command timeout) is nice, but not part of the semantics of geometry_msgs/Twist.
Navigation stacks typically use Twist messages to provide setpoints to lower-level controllers that will make the robot attain the velocities encoded in them. These setpoints are generated as part of the position control feedback loop closed by nav_msgs/Odom (or TF) and which produces velocity commands.
The entity running the position controller (fi a local planner, or something else) would be responsible for sending appropriate velocity setpoints to make the robot reach the desired location (or pose).
Almost all local planners in the nav stack (and nav2d is similar afaik) implement something like a velocity-based feedback control loop to control base platform position (ie: 2D (2.5) or 3D pose of the robot in some reference frame).
geometry_msgs/Twist does not encode something like a "unit of movement", but velocities. Both linear and angular.
The nav stack uses this message to continuously provide setpoints to the entity that is supposed to make your robot move based on those setpoints. So there is no quantum of distance that it expects as behaviour. The local planners will try to drive the base platform towards the pose they have been given (by a global planner or something else) by computing appropriate geometry_msgs/Twist messages which are then published.
nav_msgs/Odom (or TF) is used to close the loop (ie: to provide information on where the robot actually is, compared to where it needs to go).
What general assumptions (if any) does Nav2d make about Twist rate and robot behavior?
I would say that the assumption is for a consumer of Twist messages to exist and for something (not necessarily that same consumer directly, but it would be a typical setup) to cause a corresponding motion of the base platform (ie: if the planner / controller requests a linear velocity of 1m/s to be attained along the X-axis, that is actually what happens).
Implicitly there is probably also the assumption of low latency between the publisher and subscriber, and a reasonably accurate 'execution' of these velocity commands (if this is not true, you'll generally observe unstable behaviour (ie: robot oscillating, not reaching its goal position, etc)).
I see that by default (correct me if I'm wrong) nav2d produces Twist messages at a rate of several messages per second. This appears to me to be a very high rate [..]
for a(n) (on-line) control system "several times a second" is actually not very high at all. It all depends on the dynamics of the robot: small and/or lightweight robots tend to be able to "move fast", so they can better track incoming setpoints, larger and/or heavy robots (with lots of inertia) tend to need some time to catch up with a velocity setpoint, so they will not ... (more)
