Back in the days many viruses infected almost every binary they could find but these days are gone. The majority of malware is quiet now and tries to hide itself in a preferably unobtrusive place like the System Volume Information
directory which is by default locked for every user even the administrative ones. This directory is a good place to hide because it exists on every modern (and not so modern) Windows system which makes the majority of all systems targeted by malware. This is not the case when it comes to recovery partitions. They aren't present everywhere and to infect them in a way that enables them to survive the restore process might be not the easiest thing to do.
So technically there are for sure viruses that infect the recovery partition because they infect all or random binaries but they will infect the recovery partition "by accident" and mostly in a way that won't survive a system restore from that partition. I have never heard of a malware that is targeting recovery partitions in particular.
A malware developer who specifically wants to realize this needs to know how the recovery process works and this process will differ from vendor to vendor and maybe even from model to model . This increases the expense for malware greatly.
I think the general problem here is that an infected file on the recovery partition might not cause an infection on the restored system. There are some binaries but the majority of the data is in my experience stored in a image of the partition that will be restored. When the malware infects the binaries and they are executed to start the recovery process they will only run on the already infected system but after the reboot they are gone. So the attacker needs to manipulate the image and maybe even the recovery tool if it does verify the checksum of the image that is going to be restored.
Overall it is surely possible but not very efficient because it is a very specific attack that won't work on the majority of all infected systems which makes it unattractive for malware developers.