I'll answer the first question after the other questions as it depends on the answers given.
Which one should I choose? and for password-based key derivation 5 seconds delay using Argon2id with 6 iterations, 1 GB memory, 4 parallelism.
That doesn't feel well-balanced to me. The memory requirement is mainly to make sure that parallel computations are not easily implemented in hardware, specifically GPU's. I'd say that e.g. 64 MiB would be fine and probably overkill.
The OWASP cheat sheets indicate a maximum security level with parameters m=47104 (46 MiB), t=1, p=1 for Argon2id.
Now an "iteration count t of 1" may be too low. I'd set it to a value that is still acceptable on the least performant device on which the password manager is required, after setting the parallelism to the value that you want. However, I would definitely not set it to anything higher than "near instant", say 0.1 to 0.5 seconds. With a high entropy password it would be mostly security theater in my opinion.
Parallelism indicates how many threads can be handled in parallel. Generally it is set to 1. A somewhat higher count can be used to quicken the response time on the user's system, as that would only benefit the user and not the attacker. However, setting it too high will mean that all the processors will try and perform the calculation. This will generate both overhead and will likely starve other processes of access to the CPU. A value of 1, 2 or possibly 3 seems most appropriate (most ARM chips nowadays have 4 performance cores, so I'd leave at least 1 for other processes running in the background).
Does Argon2 have a maximum security level that restricts my master password's length/entropy? If I use a 12 word generated passphrase (155 bits) using Argon2 in return Do I get that 155 bits of security?
The function ends with an invocation of Blake2b, which would indicate a maximum security size of 512 bits. Nothing to worry about.
I use an offline password manager, I want to use a future proof very strong master password and I'm going to choose one of these options from the EFF's large wordlist, a randomly chosen 8 word passphrase (104 bits), or a 10 word (128 bits) or I can even use a 12 word generated passphrase... Which one should I choose?
Generally we aim for at least 128 bits of security. However, that's after running the Password Based Key Derivation Function (PBKDF), in this case Argon2id. Going higher doesn't make much sense especially when it comes to passwords. The problem is that for memory hard functions this is relatively hard to calculate.
Normally we calculate the additional amount of bits of security by using the 2-logarithm of the number of operations that are performed. The internal function G is run 2 times the memory parameter m for each iteration. That means that the OWASP recommendation will do 94204 operations of the (relatively complex) G function (which uses Blake2b internally). We can see that this provides about $\log_2(94204) \approx 16.54$ bits of security.
Personally I would be totally OK to reach about 120 bits of security, which would mean that 104 bits of entropy for the password generator would be the recommendation.
Note that the security in bits scales exponentially, so you'd need very high values of m and t to reach 20 bits of security or over. At that point it makes more sense to make the password harder than increasing the parameters / workload for the CPU. This is the disadvantage of PBKDF's in general: they only provide limited protection.
