If it was factory refurb, they need to disclose that it is factory refurb, and cannot legally sell it as "New."
That said, short of maybe a stressed battery pack, it is usually nothing that a full system re-image (like installing a custom rom does) wont succinctly take care of. (usually. Some of those SoCs have hidden nastiness inside them that the carrier uses to spy on people with, and that can sometimes become home for some really nasty malware, or so I have read. Typically, devices that have such features get discussed pretty intensely at the 'usual places', and I avoid such devices because they are fundamentally incompatible with my views on device ownership.)
I will invest a bit of time in seeing if there are ways to tweak the system's CPU activity governor for increasing the battery life. Short of disabling the bluetooth radio completely, turning off the wifi radio except when you intend to connect to a hotspot, and things of that nature (In addition to stripping down the running system apps, etc) the governor's settings will be the major factor in determining the battery life of the device, aside from if the manufactuerer should just be castrated with rusty implements in a 3rd world bathroom or not for just putting insufficient battery on a hungry device.
Basically, since Android lives on top of the linux kernel, some linuxisms get inherited, including the cpu governor model.
Here is a rather technically minded post from one of those "usual places" which discusses CPU governors (and IO schedulers) as an introductory piece, but is not for novices.
https://forum.xda-developers.com/general/general/ref-to-date-guide-cpu-governors-o-t3048957Essentially, they are algorithms to help control when and how the CPU gets moved in and out of full speed/low power modes, and how they queue up IO operations to reduce resends, improve efficiency, etc. This is especially true for things like the TCP retry methodology (which is an entirely additional read, and has roots well outside phones or linux in general, in deals exclusively with the TCP/IP protocol itself), which can radically reduce the number of packets your device sends when it has a hiccup on the network.
Power users tend to be obsessive when it comes to eeking the very last drop of either performance or utility out of a device, and will dedicate long hours to finding the exact right balance for their tastes. (Naturally, the stock roms, with their "now now mr user, you shouldnt touch that!" bullshit just wont cut it, which is why these folks bake rehashed roms all the time. I prefer something with a more auditable trail behind it, which is why I prefere android open source project (AOSP) based roms, like LineageOS. I can literally recompile and recook the rom as I damned well see fit, including adding or removing governors, poking at the schedulers, defining different TCP retry schemas, etc, by muddling the source code and recompiling.)
In a nutshell, if you want your device to stay ON for very long periods, you will want to keep the device in very low power mode for most of that time, and you do that with the governor and IO schedulers. The governor algorithm that you choose will determine what clock speed to put the devices CPU in when in low power mode, and what cpu speed to put the device in when in active use. Custom roms often allow you to overclock the cpu slightly to gain a teeny slice more performance, at the expense of service life on battery. You might want to slightly underclock for the inverse consequence. (instead of a 2.8ghz clock, might run at 2.6ghz, and eek out a few more minutes of battery per cycle without a seriously noticeable drop in performance.)
Each device and its quirks are different, and I have not used the handset that you are asking about. I will see if I can find any discussion pages on it, and see what I can learn.