No, StackGuard is not intended to protect against these types of attacks, nor does it in practice.
StackGuard specifically targets buffer overflows. When a buffer on the stack is overwritten, an attacker typically tries to overwrite the saved return address at the top of the stack frame. StackGuard inserts a canary value before the saved return address, and typically checks that it matches the known good canary before returning. If it doesn't match, then there was an overflow attempt and the program should exit.
Format strings are not buffer overflows and usually do not have the same goal. While a buffer overflow blindly "smashes the stack", format string exploits are a bit more precise. If you wanted to change the saved return address and knew the stack address where it's located, you could write directly to that address, leaving the rest of the stack (and canary) intact. This provides greater flexibility for an attacker in many cases, since buffer overflows don't allow you to simply skip over the canary.
StackGuard also has no affect on the GOT overwrite you mentioned, since this doesn't affect the stack at all. The proper mitigation to GOT overwrite is full RELRO (Relocation Read-Only). Due to startup performance costs of full RELRO, most binaries (and gcc defaults) only use partial RELRO. Partial still leaves the .got.plt writable, which is the part used for this type of attack, so it is not effective for preventing format string attacks either.
The -D_FORTIFY_SOURCE=2 option to gcc prevents strings stored in read-write memory from using the %n specifier, preventing an attacker from overwriting memory. It does not prevent read primitives, however, so an attacker may still be able to leak critical data from the stack (e.g. the canary).
