I tested the leaderboard and devroute with both pure pursuit only as well as stanley and pure pursuit. There seems to be no difference between Leaderboard and devroute. As explained in the Note this might have been because the devroute once was asnychronous. Now the devroute is synchronous as well.
I have also shortly tested with the acting debug node which starts an asynchronous dev test. Visually there was little?no? difference. (Only tested a few hundret meters with the lanechange trajectory).

There is however another difference between the trajectories from acting-debug and those of planning. The acting-debug trajectories are interpolated to 25cm, so there are probably more individual points along the trajectory.
This has to be kept in mind when designing the local planner in the acting architecture #489 ("How exactly is the interface to pure pursuit?")

This also lead me to a correlated bug with the pure pursuit controller:
When searching for the next point ahead only such poses from the trajectory will get accepted that have a higher index in the trajectory than the previous one. If trajectory doesnt change this is fine, but if not (and planning does this for lane changes etc.), we run into issues (Probably also bit me in this bf0c110). The following link shows the code line where problem occurs:
https://github.com/una-auxme/paf/blob/d63c492cb30b3091789dfd2b7179c65ef8c4a55a/code/control/src/pure_pursuit_controller.py#L172C9-L172C63

Especially with new local planner we will need to fix this. In the commit to this feature branch (f700710) I added a partial fix in the comments. However if car turns more than 90deg from wanted direction we drive the route backwards.
The information in what is next lies in the indices in the trajectory. We need to cleverly ignore this information occasionaly or use it in a different way however in order not to run in above mentioned problem.

From my somewhat unreliable memory: there was a time when the devroute used sensors without any noise.

Back then, the input to the steering system was based on the vehicle’s deviation from the global route. This noise caused fluctuations in the control error, leading to steering overcorrection.

If I understand your recent changes correctly, instead of the global trajectory appearing to shift relative to the vehicle, the desired trajectory is now anchored to the vehicle itself.

This adjustment might have reduced the impact of steering overcorrection.

Following the Note with GitBlame we find it was created at the end of last semester and didn't appear before. Also we are still driving on a global trajectory influenced by noise in kalman estimation, so there should not be a difference to when the note was created. Still I cannot find clear evidence why pure pursuit would perform worse. Also this github action ran with only pure pursuit and performed no different to others.
(Still of course pure pursuit feels different than stanley, which is to be expected and isn't in a negative way)

This issue came up again because we are trying to implement local planning algorithms which will need a steering algorithm for a localized "trajectory" and early tests saw pure pursuit failing in this regard. The reason for this is the bug in code as mentioned in my first comment. I will therefore open a bug issue for the specific problem (#567).

Regarding this issue we might be able to close it. With the new acting component (aka. a local planner) requirements for steering controller will change anyways and more specific issues such as the one mentioned above might arise. Still there shouldn't be worries regarding the omitment of stanley while focusing on pure pursuit.