For now, we have public key hashes as outputs and then it is needed to reveal public key and signature in inputs. But the properties of ECDSA allows us to skip this public key and by having some address and some signature, it is possible to verify it (in exactly the same way as we can type some address and signature and verify any message, not necessary being a transaction). Then, why storing public keys in the blockchain is needed if they can be safely skipped and calculated from signature and address?

To verify an ECDSA signature you do need the public key (R = (x_R, y_R) = u₁G + u₂Q_U where Q_U is the public key).
In fact you need 3 things: signature (r,s), the public key and the message that was signed (ie. the tx).

Because:
1. In ECDSA we can recover public key from signature + message but we may end up with more than one possible pubkey (up to 4 for secp256k1 with h=1). So we may have to verify the signature multiple times to see which pubkey is valid and that wastes a lot of time since the verification is an expensive process.
2. Recovering possible public keys is an even more expensive process that would slow down verification of blocks if pubkeys weren't present.

Signing the same message results in the same signature, provided that the r value is deterministic. Even if it's not, it is fine as long as the r value is not reused. I don't think signing the same message would expose you to any risk.

If only the message really did have the timestamp autoinserted into the text then we wouldn't have this problem. Alternatively there could be another input field after the message text called something like "timestamp" where this info is filled in by the wallet and put on the last line of message text by itself and also under the address after the ===BEGIN SIGNATURE=== line. Just like we have an input field specifically for the address [which I know its public key is used in the signing so the question of where to put it in the message is moot].

Can you explain this further? Why can you end up with up to 4 public keys for secp256k1 with h=1? (I guess with h you mean hash of the message)

It requires a couple bits of auxiliary data to do this, it slows down validation (by about 20%), it's incompatible with batch validation (ECDSA itself is too, but if you were going to add aux data you could batch validate and get a 2x speedup instead of a 20% slowdown), and there is a patent claim on the technique.

It also only saves 12 bytes compared to just using the public key, and that 12 byte savings comes from using a 160-bit hash instead of a 256-bit hash which reduces security to only 80-bits in cases where collision attacks matter (e.g. when multiple parties collaborate to generate a key).  If you use a 256-bit address hash to preserve ~128-bit security then there is no space savings at all vs using the public key directly.

Ironically, I also thought I wrote a similar reply... searched for it, couldn't find it... so just wrote it again.