For some modes of operation you can easily show that an involution would be insecure:

• OFB would be most clearly insecure, since the keystream just repeats the nonce/IV and its corresponding encrypted block.
• CFB would likewise be insecure, since zero blocks encrypt just like with OFB. This is of more limited advantage to an attacker, but far from secure.
• CBC mode again has problems with zero blocks, since the following block's ciphertext can be decrypted simply by XORing it with the ciphertext of the block two back.

Similarly, CBC-MAC, including some of its variants, would be broken, because adding two blocks of zeros anywhere in the message would not alter its authentication tag.

Now for the handwavy part.

With CTR mode you are going to have worse bounds on the amount of ciphertext you can encrypt. Normally CTR mode is secure up to roughly $2^{b/2}$ blocks, because at that point you would expect outputs to collide with a PRF but not with a PRP. Equivalently, at that point you expect ciphertext blocks to collide, which tells you that the message blocks differ.

With an involution you have the additional case that the output may collide with another input block, which tells you the corresponding output. That has an equal chance of happening, doubling the chance that one of these cases happens and thus about halving the amount of data you can encrypt. (Or reducing it by a factor of $\sqrt{2}$, but close enough.)

However, beyond that I think CTR mode would remain secure, as long as the attacker cannot control the nonce.

AEAD modes like GCM are much more complicated to analyze, so I will not attempt them.

For some modes of operation you can easily show that an involution would be insecure:

• OFB would be most clearly insecure, since the keystream just repeats the nonce/IV and its corresponding encrypted block.
• CFB would likewise be insecure, since zero blocks encrypt just like with OFB. This is of more limited advantage to an attacker, but far from secure.
• CBC mode again has problems with zero blocks, since the following block's ciphertext can be decrypted simply by XORing it with the ciphertext of the block two back.

Similarly, CBC-MAC, including some of its variants, would be broken, because adding two blocks of zeros anywhere in the message would not alter its authentication tag.

Now for the handwavy part.

With CTR mode you are going to have worse bounds on the amount of ciphertext you can encrypt. Normally CTR mode is secure up to roughly $2^{b/2}$ blocks, because at that point you would expect outputs to collide with a PRF but not with a PRP. Equivalently, at that point you expect ciphertext blocks to collide, which tells you that the message blocks differ.

With an involution you have the additional case that the output may collide with another input block, which tells you the corresponding output. That has an equal chance of happening, doubling the chance that one of these cases happens and thus about halving the amount of data you can encrypt. (Or reducing it by a factor of $\sqrt{2}$, but close enough.)

However, beyond that I think CTR mode would remain secure, as long as the attacker cannot control the nonce.

AEAD modes are more complicated to analyze, especially when they use the same key for encryption and authentication. GCM is probably secure, since its security comes down to that of CTR both for encryption and authentication. Others like CCM might not be, due to the use of CBC-MAC.