Hi @shirokane! A sensible question, with an unintuitive answer. Or several answers really.
Ok so a bit of history: Arc Timeline (and also Arc Mini) have for many years used a system of dynamic sampling rates. If it’s an activity that benefits from higher frequency sampling, it’ll do so, while if it’s an activity that doesn’t need that extra data resolution, it eases off. So the sampling frequency could be anything from every 2 seconds to every 60 seconds.
The new Arc Editor (in TestFlight beta) also does this, using a similar system for dynamic sampling rates per activity type. So for example if you’re walking or running it’ll be sampling around every 2 seconds, while if you’re stationary at home it might be sampling every 60 seconds (or every 2 minutes if it’s gone into Sleep Mode).
Now another historical detail, that doesn’t carry over to the new Arc Editor app, is reduced sampling when battery level is low or when the phone is in Low Power Mode. Old Arc Timeline app still does this, but turns out it’s probably largely pointless. Basically that system would do something like halve the sampling rate again, if battery level is low or phone is in Low Power Mode.
The reason why that’s probably largely pointless is that that recording doesn’t actually use much battery at all. It’s an optimisation for a part of the system that’s already very low energy consuming.
And there you guessed right! It turns out it’s not really useful at all. Intuitively it seems obvious that it would be, but in practice… nope.
Well, there is a caveat: Google Timeline and other apps with similarly extremely low detail recording use a different system, which is much lower energy consuming. That system is either the “significant location updates” system, or “distance filtered” updates (eg no location updates until the distance from the previous is more than X metres).
The significant location updates system is very low energy consumption. But it’s also next to useless. If you’ve ever used Google Timeline you’ll know that the data it records is … not great. And by not great I mean really quite awful, unless your goal is to have a barely useable timeline of Visits, with almost no usable Trip data between Visits. Significant location updates are designed for very simple tasks like knowing whether the user has moved from one area of the city to another, or at best one building to another.
The “distance filtered” location updates system is … well, that’s actually what Arc Editor uses now. That stops updates flowing in if they’re not useful new info in terms of the resolution the app needs. That does marginally reduce energy consumption, in a way that’s workable for each app’s detail needs. But by “marginally” I really do mean marginally. It’s not a significant energy saving in any meaningful way.
So what does cause high energy drain? Screen time. Foreground time. Map updates. If you have the app in the foreground and you’re browsing around the data, looking at different details, the map is updating as you go… that will be using orders of magnitude more energy/battery than the actual location data recording.
As a rough metric, think something like 5 minutes of foreground time, browsing around the app, being equal to let’s say 5 hours of location data recording. It really can be that dramatic a ratio.
The most energy expensive parts of an iPhone are the screen and the CPU/GPU. When the screen is lit up and on, you’re chewing through battery. When the CPU/GPU are busy doing things, you’re chewing through battery. So when you’re browsing around the app you’re paying for that screen time and also all the CPU/GPU work required for loading data, manipulating it for display, updating the map, etc. That’s where all the energy consumption goes.
So … long story short: To save battery, don’t turn your screen on and use apps in the foreground 
Not the most helpful advice, I realise, but yeah, that’s what eats all the battery.
For the actual location/timeline recording, I used to do daily statistics collating of that across a bunch of different iPhone models, years back when batteries were much smaller and weaker. The results showed that Arc Timeline could basically record continuously in the background for 24-48 hours on a single battery charge (depending on phone model - the Max models being the ones that got up to around 48 hours).
Of course no one leaves their phone untouched, with zero screen time, so no normal phone would get that 24-48 hours on a single charge. That was just test devices that were doing literally nothing other than being there to run Arc Timeline, in my bag that went everywhere with me throughout the day. But the point stood: the actual location/timeline recording almost didn’t matter at all in battery terms. It really was already absurdly energy efficient.
Hope that helps to explain! Cheers 