TL;DR: For drivetrains? Nope. For other stuff? Probably not.
To preface this, in case you didn’t know: V5 motors include their own encoders and their own motor controllers, and can run their own PID loops internally.
Most of the autonomous inconsistency people are describing is due to wheels slipping on the foam field tiles when the robot abruptly starts or stops. Invictus, the world skills champions last year, used 2D motion profiling in order to limit the acceleration of their robot. Because of this, they were able to achieve very accurate autonomous routines without writing their own PID loop. I would highly recommend using PROS and OkapiLib to accomplish this. Check out their YouTube video of their skills run, specifically the comment section, if you want more information.
For drivetrains, you should not code your own PID loop, full stop. If you run your own PID loop on the V5 brain, your loop will have to wait for the 10ms delay to get encoder data and then wait for the 10ms delay to send motor data. This is far slower than the PID built into the V5 motor, and if you try to implement it, you will either end up with a very slow-moving drivetrain or end up with oscillations due to the loop latency depending on how you tune your PID constants.
For other mechanisms (lifts, arms, etc.), it’s a bit more complicated. You can either use the motor’s built-in encoder coupled with a limit switch, or you can use an external potentiometer. Neither option is very good.
Using the motor’s integrated encoder gives you very good PID loop performance, but will make your mechanism’s movements less accurate overall if there is too much chain slack or gear slack between the motor and the mechanism (lift, arm, or whatever it is). Because the rotation sensor is mounted to the motor shaft, not the output shaft, any slack between the two will result in incorrect readings and inaccurate movements.
On the other hand, you could mount a potentiometer to the output shaft and run your own PID loop. If you do this, you end up with the same oscillation and slowness issues as before, but at least your movements will be accurate.
I’d prefer the first option if the mechanism uses gears, but if the mechanism uses chain, I’d go with the second option. Or try and redesign the mechanism to not use chain.
Edit: On the topic of drift correction, Invictus again had a great idea. They periodically read the motor encoder values from each side of their drivetrain, calculated their absolute angle since the start of their routine, and turned to compensate for it. This fixed the rotational drift issues. For position drift, they periodically lined themselves up using other field objects, such as the poles in Turning Point.