This is a really good question that sheds a lot of light on 3D printer software/firmware architecture, and Tom already said a lot of the things I wanted to say before getting a chance to write an answer. The basic problem is that, to do pressure advance accurately (and in a way that doesn't get it horribly wrong when inaccurate), you need to know the actual feedrate of the extruder at all times, and that's not available until applying the acceleration profile, which by convention happens in the printer firmware.
With that said, there were primitive and even somewhat advanced attempts to do pressure advance in the slicer. The first seems to have been "coasting", which, along with extra-priming after coast, is pretty much just "pressure advance, assuming a constant feedrate". It gets things horribly wrong if you mix different extruder feedrates (different print speeds or line widths, etc.) or if you have slow acceleration, but if your acceleration is so fast (relative to max speed) that it's approximately instantaneous, it might work okay.
Modern Cura also has Flow Rate Compensation, which is something like pressure advance. It's rate-sensitive, so in theory it can give accurate results with varying line width and print speed as long as acceleration is close enough to instantaneous. Since it appeared after Marlin added linear advance, I never bothered trying to play with it, so I can't speak to whether it actually works decently. There are still a lot of subtleties to when the advance is performed that it could get wrong, and I think you'd want to do some test cases just to read the gcode output and evaluate whether what it's doing is sufficiently close to reasonable.
If you wanted to do full pressure advance in the slicer, you'd need to let the slicer handle acceleration profile, breaking lines up into small segments each with nominal feedrate matching the rate they should end at, and sufficiently close to the rate they should start at, with the firmware acceleration limits set to accommodate the change. Then, knowing a very good approximation of the actual toolhead and thus extruder feedrate for each segment, you'd know the advance to apply, and could apply it as an additional subdivision at the end of the previous print move. And then in theory, it all works out. But this would make the gcode a lot larger/bulkier, and more demanding on the serial link speed and microcontroller's ability to keep up with parsing/planning. So it's almost surely a bad idea.
The Klipper firmware does this differently. It does the gcode parsing and planning (including pressure advance) in Python software (with some C for critical paths) running on a much more capable computer, and sends the precise generated stepper motor timings over the serial link to the microcontroller operating the printer hardware.