In I2C, the clock only toggles as necessary to transmit or receive data. There's no need for a continuous clock signal so variation in the observed frequency should be expected. The 100kHz specification is the maximum clock rate rather than the average or continuous clock rate.
Non-volatile memories like Flash and EEPROM need a relatively long period of time to write data into the memory, and 5ms sounds about right. You must not try to execute multiple write operations without allowing for this delay between them. Because of this, you cannot possibly execute more than 200 write operations per second and still allow 5ms per operation.
Once you have everything working correctly, you should expect to see a burst of 100kHz clock pulses every 5ms or so.
A book could probably be written on this- I'll try to cover the high points.
The WDT is a tool that can be used to help satisfy some system-level requirements, and those requirements are the primary motivation. They could be safety-related or arise from a desire to reduce some annoyance to the user. There are other tools such as clock monitors, external WDTs, redundancy, interrupts on access to improper memory locations, interlocks of various kinds, etc.
A WDT will not prevent anything- it can be used to help recover from a system upset. When a WDT timeout is triggered, you know something really bad has happened, but you don't know exactly what, so you must begin some kind of recovery operation. The processor could have gone off and done all sorts of things- corrupted memory (RAM or EEPROM), re-written SFRs to improper values, set outputs to undesirable states etc. The first thing you need to do is to put the system in a 'safe' state if that is a concern, and if it is possible. For example, a 10kW heater should be switched 'off' in most cases (there are cases where 'on' is better). Some things (consider a drone autopilot) may not have a safe passive state, and you may have to resume operation and attempt to recover.
Before resetting the WDT (as you say, it should happen in the main routine) you should check as many things as possible, not just that you got to the reset routine. You may wish to confirm that known values such as SFRs have not changed (or re-write them if that does not disturb things). It's a bad idea to depend on power-on default values. It's possible to set flags that indicate error-free completion of important operations- you can make the flags persistent (flag an error and never reset it) then if your WDT reset routine finds that the flag has been set it has the option of performing a complete recovery.
It's good practice to have the WDT reset fenced in by jumps so that you can't run into it by accident (say by executing NOPs in unused memory). Some WDT implementations have a window function that requires a minimum time between resets as well as a maximum, which prevents some unanticipated routine from resetting it accidentally.
As far as the WDT time-out- you want to make it short enough that nothing bad can happen, or the WDT will not be that useful. In the case of a thermal system, a couple seconds might be no problem. In the case of motion control system, milliseconds might be better. Too frequent and you may have problems resetting it frequently enough.
It's better to have a WDT that cannot be disabled from firmware and cannot be set to a too-long timeout (which is almost the same as it being disabled). Usually well-designed processors have some protection against an errant processor doing that sort of thing.
In the case where you have to reset it very frequently, but you have a very slow control loop executing, you can use a flag or a timer to indicate a problem in the slow routine and reset the WDT if it times out. That, essentially, adds a software WDT to the slow routine.
An example of that might be a motion system that does a self-tuning algorithm in the background. You need a very fast WDT to prevent the system from making undesirable movements, but the self-tuning takes longer.
Best Answer
If both timers are run from the same clock source (a divider doesn't matter) and you do not stop and restart those timers manually, there will be no delay between them since the timers work synchronously (they are bound to a clock). Yet, your clock will probably be skewed over time (but both timers will be skewed by the same amount), so you might be better off with a dedicated RTC.
You could then connect the seconds interrupt of your RTC to an external interrupt input and rely on this source.
I am not quite sure why you would need two timers for this task as this is something which can easily be accomplished by a single timer if you do not care for a few non-accumulating clock cycles delay (which are used in your main loop).