Most likely, once you get fully synced (both bc and wallet (wallet may need to be deleted/recreated after bc fully syncs)) your pooling will come back. If not, that info is in your old config.yaml, so can be copied over (do not do that before full sync).
When you are syncing, your node is processing more blocks per second than in a normal run, so I would not worry about warnings about your node being slow. However, that’s a warning that you may want to plan to act on. I would seriously consider getting a PCIe to NVMe card and an NVMe (Samsung 970 evo plus (runs hot, needs some fan, but fast and reliable), WDC black (fast and reliable)). SATA SSD is kind of a borderline, especially during dust storms. In your case, the box is rather weak (slow), so could be sensitive to slower NVMe / SSD. I think that the price difference between SSD and NVMe may not be that great, so the penalty is that PCIe to NVMe card (maybe $15-20). There is no point of getting PCIe 4 NVMe, as most likely you are running on PCIe 2 slot right now.
The syncing process is really heavy on the db side and has plenty of small / random place updates. So, that will put a strain on any HD (array or not) on the stepper motor(s) (head movement). This really degrades HD read / write performance. Again, HD RAID works for plotting as both reads and writes are sequential and in big chunks and there is not much disk fragmentation. However, for farming (syncing), db is being updated constantly making it a highly fragmented file, thus hard on any mechanical drive.
As I mentioned, the code is rather single-threaded and serialized, so just looking at the overall CPU may not give the whole story. If the main node process will max out its core (25% of CPU in your case), nothing else will be processing at that time, so the other 3 cores will go idle. Once that thread will finish the job, it will dispatch most likely 3 threads for block crunching. So, not knowing the details, your CPU chart may be showing exactly that (that 100% burst is when the blocks were processed). At the same time, if that main thread will be stuck on HD side it will not be maxing out one core. So, maybe what is on that chart reflects that (maybe you can change sampling rate to a bit longer). Just run top (or bpytop) to see what processes are taking the CPU time. (By the way, the main node process has the same name as the block processing ones, so the count of those processes shows where the processing is.)
As far as those changes in config.yaml, check what are the names of dbs you have right now (bc and wallet should have V2). It looks like that in the latest chia version, the default is V2, so no need to modify config.yaml. Here is an old post about those db names - Chia Blockchain 1.3 Beta released - #16 by Jacek