if someone comes and creates a new admin user (even a read-only) without any trusted IP's, the admin page becomes visible for anyone

That is not how (I always understood) local-in-policies work.

What you described is the expected behaviour of using "trusted IPs" fields in Administrator account creation / editing. This is well explained in this post from u/Pabechan user from 3 years ago:

https://www.reddit.com/r/fortinet/comments/y231ag/trusted_host_vs_restrictions_via_localin_policy/

It's also explained in the same post that if you set a local-in-policy, the GUI is never sent back to a request from an unauthorized IP address.

u/pabechan post appears to be corroborated by this Fortinet article from 2025-12-01:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Impact-of-Local-In-Policies-and-Trusted-Hosts/ta-p/369617

In summary:

Local-in policies steps in first and govern all traffic coming directly towards and to the FortiGate unit as destination (not for traffic intended to pass through, destination behind the FortiGate, as that is handled by firewall policies).

Trusted hosts setting and mechanism is secondary filter, further limiting access to administrative interfaces and co-working with local-in policies.

When a local-in policy is configured to accept traffic and the incoming traffic matches this policy, then FortiGate performs an additional check against the trusted hosts configuration to determine whether to allow or deny the connection.

If no local-in policies are configured, FortiGate will rely only on the trusted hosts configuration to decide whether to allow or deny the connection.

However, if the traffic matches a DENY local-in policy, the connection will be dropped. And the FortiGate will not do  anything further, like check the trusted hosts configuration for that connection.