I hope you tested it yourself before applying such changes. Did you?
Well that are keys for verification. How would verify keys which are there for verification?
No idea what you mean by that As I know gpg keys can change quite often. The problem though is that the if you didn’t update and skip one keyring update, it will not be able to verify the keyring package and result in that error.
I have not deep knowledge when it comes to gpg, but in my view it makes no difference if you get the keyring from an unverified package or retrieve it from a server. The verification of the package is just an extra security measure, but the missing of the package verification of keyrings would not reduce security in any way.
The signature is there to verify that it has not been tampered with on the server, client or during transfer.
The public keys make sure of this.
However, if I control the keyring package (because you disabled the verification) I could add my own keys and sign any package (e.g. firefox or keepassxc) and your system will happily install my package.
Maybe, but we are talking about pacman where gpg verification is optional and not a requirement. It is by design a security measure on top of it although enabled by default (opt-out).
Well installing the package does population already, but don’t connect to a gpg server and refresh the keys. Doing pacman-key --refresh needs a lot more time by the way.
In my view, Manjaro’s mirror is the origin. There I have more trust and I would consider disabling gpg verification there if necessary. If it is a mirror of Manjaro’s server, then I would really care to check if the package is really one from Manjaro, so that it wasn’t manipulated somewhere in between. Therefore I strongly consider to use gpg verification.
About the script:
Well… maybe add a line to switch to another local mirror before doing a full upgrade?