Because may wav file recording errors were not detected in 2.x, in 3.0 I added many checks of the wav file which may account for some of the increased CPU utilization.  In addition, in order to support FST4W decoding, in 3.0 wav files are each 1 minute long and are assembled into 2/5/15/30 long wav files as required by the decoding modes.  Doing that incurs both CPU and memory space costs.  For configurations which decode only WSPR-2, I think most sites can continue to decode 14 bands on a Pi4, although at KPH I found the Pi4 was occasionally running out of CPU time and thus I reduced the intensity of the 'wsprd' efforts by adding the line:
WSPRD_CMD_FLAGS="-C 500 -o 3 -d"
to the config file.
At WA2TP which is much closer to the East Coast and European beacons I needed to reduce it even further to '-o 2' with:
WSPRD_CMD_FLAGS="-C 500 -o 2 -d"
However I think even '-o 2' incurs only a small penalty on decode sensitivity, since that Pi fed by one dipole and logging as 'WA2TP-1' is #11 worldwide and not far below the #6 WW 'WA2TP' which is fed by 5 antennas all decoding at '-o 4'
Reducing the '-o' level will not help FST4W decoding, so many of the top spotting sites already have moved to using i5, li7 or i9 WD servers. Doing so will allow them to decode FST4W beacons and I hope will encourage more LF/MF/160M sites to migrate to that mode since their transmissions will get many more reports.