The battery won't have any significant effect. Time is stepped at system startup. It's better not to have a totally bogus system clock during system boot, because it could be messing up timestamps etc., but this shouldn't be catastrophic.
The PC platform is a disaster. It was designed back in the 8088 days and has evolved continuously from that state by numerous PC manufacturers and CPU designers, each of whom have had their fingers not only in the pie but often grabbing handfuls. As a result, there are multiple potential sources built into your PC, some of which are better than others.
The original RTC chip on the PC is difficult and slow to access, unable to provide precision time of any sort. This is generally only used for bootstrapping the idea of time (and why I say the battery won't have any significant effect).
The HPET system was designed as a replacement for that, but poor design, a lack of mandate, and some other factors have meant that it isn't available on every platform and occasionally unreliably implemented.
The i8254's Programmable Interrupt Timer (PIT) was one of the first alternatives to accessing the RTC chip directly but hasn't been reliably implemented even in the early days when it was discrete hardware.
Starting with the Pentium, the Advanced Programmable Interrupt Controller (APIC) offered a potentially better source of interrupts, yay progress, but in practice there's a bunch of errata that made this a problem to work with in the real world.
The Time Stamp Counter (TSC) is basically an instruction cycle counter local to the CPU. Unfortunately, in this era of multiple CPU cores, that introduces a bunch of challenges, and then it is also affected by stuff such as CPU C-states (idling) or P-states (lower clock) or T-states (thermal throttling), meaning that the count cannot be directly used to drive time. Because different CPU's have different specifics, the art of deriving a consistent data source from TSC is a bit messy. For TSC this is complicated more by potential BIOS settings for power efficiency.
So FreeBSD's method is to pick one that looks okay, and let the user override it through the sysctl kern.timecounter.hardware mechanism if needed.
Your biggest risk in changing this is that you are hitching your wagon to a different and potentially also problematic horse. The upside is that at some time or other, someone was totally dependent on each one of these clock sources for their time, so a lot of effort has been put into making each one as reliable as possible given the caveats. Whether it'll work for you is unknown, of course.
