I don't know what's the better choice: use only one timer in the game
loop to update everything in the game, or an independent timer in
every object that needs one.
A single timer is a viable option in many cases, but while one-time-per-object might be a bit overkill, there are good reasons to have multiple timers and/or time sources.
In general, you want one time source for each batch of things that should operate on the same timeline. Typically you'll have all your game logic objects slaved to a single time source, but you might also have a few extra timers for rendering systems -- perhaps one for the primary in-game rendering and one for interface rendering.
The reason you'd want to do this is because it allows you to implement certain behaviors very easy by simply scaling your time sources relative to real time. For example, you can implement game logic pausing by forcing the per-frame delta time returned from that time source to be to zero, or you can implement a "slowdown" effect by scaling that delta time by some factor, such as 50%. If your object updates are correctly written to handle it, you can even rewind time this way.
If you do that you'll want to be using a different time source for things like your HUD render effects, otherwise they would slow down (or pause!) when the game logic did, which would likely render them unusable.
It is often useful to separate out the actual real-time clock from the presentation of the per-frame time deltas (the actual time source), allowing you to drive multiple time sources off any given clock to ensure you're using a single canonical "current time" and simply scaling its delta appropriately in each source. There are also reasons to use a separate clock entirely for things like physics, which tend to work better with fixed time steps.