Actually this is fine. I might even argue it is the best way to do it :-).
The automatic update notifications in Fedora Workstation use PackageKit. They do not use the dnf command.
You can see that pkcon installs packages successfully, (or updates with pkcon -c 1 refresh && pkcon update (explanation of -c here)). It does not prompt about the key. Nor does it install the key in the store used by dnf; if you run dnf again it will still prompt to accept the key.
This surprised me, because the keystore used by dnf is actually rpm. PackageKit acts as a frontend to rpm, but apparently it does not populate the rpm keyring or rely on it for verification.
You can see that PackageKit instead saves keys in e.g. /var/cache/PackageKit/25/metadata/fedora/gpgdir/. Arguably this makes more sense than the traditional organization. This way, it is possible to tell which keys have been downloaded for which repo.
Unlike dnf, PackageKit does not prompt to accept keys from the configured URL. (Note that if it did prompt to save this file in /var/cache, strictly speaking this file would not be a pure cache, as it would also represent user configuration :-).
The lack of prompting does not decrease the security of Fedora, because e.g. /etc/yum.repos.d/fedora.repo says to load the key from a file, which has already been installed (by the fedora-release package). The prompting by dnf would also be skipped if you used scripts with dnf -y install - this being the standard way to avoid prompting when the installed package has additional requirements. (The Ansible dnf module does the same thing).
I conclude this prompt by dnf is not considered to serve an important purpose. Considering the scenario in the question, it would probably be better to remove the prompt that says "warning", and asks "Is this ok". (And it would be best to fix libdnf to use the same pattern as PackageKit. From a security position it seems quite strange to keep old RPM keys around indefinitely.
EDIT: in newer versions, both PK and dnf are now implemented using libdnf. So there are even fewer excuses to not fix this :-).
Other repos like google-chrome.repo might rely on downloading updated keys over HTTPS. This has different security properties. In particular, it seems less likely that key pinning and HSTS (as used by the main HTTPS clients) have been implemented for PackageKit. I am unclear why this possibility was implemented in the first place, i.e. downloading updated keys using a method with different security properties. At minimum, it seems an argument for not keeping downloaded keys in /var/cache/, which the user may wish to clear when they have an urgent need of disk space.
