Reasonably designed embedded device like that should be using a watchdog timer which automatically restarts it if code gets stuck (it's a basic hardware level feature available in almost all microcontrollers), and any crash should also cause a reboot.

Considering the nature of product there is no interactive interface, it doesn't perform any critical operation like motor or heater control which couldn't be easily interrupted and resumed a fraction of second later after the reboot. In case of memory leak or some kind of memory allocator error it would also be safe to reboot. User wouldn't even notice if this happened.

So even if something goes wrong, chance of it being uncrecoverable seems low. It would need to be either some kind of persistent storage bug causing it to get stuck in a bootloop (in which case battery change wouldn't help either), or high level logic error preventing normal functioning while keeping the main loop running without crash or getting stuck (writing code in higher level programming language wouldn't prevent a logic error).

That's a very good point. The system design of the airtags assumed a much shorter battery life, which may have led to decisions that would introduce issues at 10x battery life. Thinking more like overflow issues. But could also be a complete non-issue. Hard to say.

AirTags get updates regularly, so they'd probably get power-cycled sooner than that.

I would also imagine someone with a fleet of these would be pretty cheesed if Apple rolled out an update that drained some fair fraction of users' batteries, no matter how fast they fixed it.