You can actually combine the two, and its important to do so for more aggressive driving.
This is my understanding of what 254 did in their 2017 code which used pure pursuit:
Wheel Odometry + Gyro tracks (x,y,theta) of the Robot, which is fed into a pure pursuit controller on a planned curve. But, Pure Pursuit only tells you what curvature to drive along; it doesn’t tell you how fast to drive. This is partially handled with things like adaptive pure pursuit or feed forward pure pursuit, mostly vis a vis stability.
Here is the paper 254 references in their code: https://www.ri.cmu.edu/pub_files/pub1/kelly_alonzo_1994_4/kelly_alonzo_1994_4.pdf
What they actually did, if I read their code correctly two years ago, is run a single motion profile along the path they are driving (that takes into account things like how turning lowers your max speed), and then also dynamically update a profile on the arc they drive to return to the path. This second profile links in to the first at the look-ahead point. That’s how they get their velocity commands.
The difference is that with “normal” Pathfinder-style motion profiling, you generate commands for each wheel side and then execute them. With the 254-style approach, you generate a profile for the velocity of the robot that gets updated with the tracking error, and use that velocity with the Pure Pursuit curvature command to generate wheel commands on the fly. That doesn’t necessarily make Pure Pursuit more accurate, especially with drift in Odometry integration. You may also find that re-running the same commands is perhaps more reliable than integrating Odometry when moving over an incline (think of the HAB); but I can’t say either way there.
Of course, I didn’t write their code, so my reading could be wrong.