If symetric cryptography is about using the same key for encryption and decryption, then what's the logic behind decrypting data with a different key than the one used to encrypt it?
Operations consisting of multiple steps of applying the same cipher - in either direction - with each step taking the output of the last is often an attempt to increase the effective key length when using a cipher with a short key[0] (such as DES, which uses 7-byte keys, too short for real security today). For example, in 3DES (DES with three steps), the effective key security is 112 bits instead of 56, and a single Encrypt operation consists of encrypting the input with K1, then decrypting the result with K2, then encrypting the second result with K3 (which is sometimes the same as K1, as here). The Decrypt operation is the reverse: decrypt the ciphertext with K3, then encrypt the result with K2, then decrypt the second result with K1 to get the original input again.[1]
If you encrypt and then decrypt with the same key (or indeed decrypt and then encrypt with the same key) - such as if K2 were the same as either K1 or K3 - the result is effectively a no-op. You have to do something with the intermediate value - such as encrypt or decrypt it with a different key - for all that computation to have any actual effect at all.
What's the difference between this scheme and a scheme like: encrypt(with K1)->encrypt(with K2)->encrypt(with K1) which seems more logical?
As far as I know (not a cryptographer, though): it doesn't matter. Triple-DES (a.k.a. 3DES and TDEA) did it that way, but Wikipedia implies that the reason is just so that "keying schedule 3" produces identical output to single DES (which is, frankly, a questionable reason to do something). As far as I can tell, it could have been E-E-E/D-D-D instead of E-D-E/D-E-D without impacting the security (but an actual cryptographer may know better than me).
The use of three or more steps in general helps mitigate meet-in-the-middle attacks, which allow recovering the encryption key of a multiply-wrapped encryption scheme much faster (though with much more data needed) than naively brute-forcing the whole combined key. In effect, you break the total key into two pieces and brute force each individually; for short keys like DES this is viable and means a two-step scheme like E-E or E-D, even with two full completely independent DES keys, would be only slightly more secure than a single DES operation with a single key. Note that even three-or-more-step constructions are vulnerable to meet-in-the-middle, but you do get some meaningful increase in key strength (for example, 3DES with 168 bits of independent key material is considered to have only 112 bits of effective key strength; that's a worse ratio than most symmetric ciphers but still MUCH better than the 56 bit strength of single DES though, without needing to invent a whole new cipher[2]).
Meet-in-the-middle attacks do require having a plaintext-ciphertext pair available (you can't use them to decrypt something if you don't have any way to see a plaintext and its associated ciphertext with the same key, though of course if you do have such a pair you can use the recovered key to decrypt any other ciphertext encrypted with that key), but for a MAC it's catastrophic; the MAC is the ciphertext (so an attacker would always have a known plaintext+ciphertext pair) and key recovery would completely negate the point of the MAC (the attacker could tamper with the plaintext and then re-generate the MAC such that it appears authentic).
[0] It can also be a way to handle multi-party encryption, where a ciphertext is created by multiple parties each with their own key, and it can't be decrypted without each party's key again. There are other ways to achieve that, though, and since the same party presumably has both K1 and K2, that's not what's going on here.
[1] This implies an interesting fact: in most symmetric ciphers, the choice of "encrypt" and "decrypt" algorithms are merely conventions, and it would be equally secure to invert them. For example, you could encrypt with DES' or AES' or XChaCha20's "decrypt" operation, and encrypt with the "decrypt" operation (caveat: I'm not sure if this applies in all modes of operation, though I didn't immediately think of any where it wouldn't as long as you did it within the mode rather than inverting the "encrypt" and "decrypt" steps of the whole mode). In fact, for stream ciphers like [X]ChaCha20, the "encrypt" and "decrypt" operation are literally the same thing! You can take an input, "decrypt" twice with the same key, and you'll get the same input back again (or "decrypt" it seven times, and get the same result as if you'd "encrypted" it three times).
[2] Unfortunately, DES has weaknesses besides its short key length, such that even 3DES is insecure for many uses and has been completely deprecated from most uses such as TLS, SSH, VPNs, file encryption, etc. We do in fact have "a whole new cipher" - several of them, in fact - which don't have DES' flaws.
