It's called _attestation_ and Windows has been doing it for some time now with VPNs and domain credentials. Attestation actually makes it possible for BYOD to be done in a way that's not going to simply repeatedly expose one's network to every kind of malware known to man.
On ChromeOS, you can filter your own access to websites. You cannot filter other users' access to websites. But signing in to a remote management can filter other users' access to websites. This grants the remote management privileges that the user doesn't actually have.
Not if they lock down that setting via GPO and let the default behavior of remote > local. There's a lot of settings that can't be undone in the GUI and take diving into the registry to undo when set by GPO but then they'll just get re-applied on GP refresh anyways. Talking about who can do what is immaterial to how domains and remote management actually work if they're not designed how you think they should be. The remote admin will always have more control than the local user in this situation, it's been that way for a very long time now and is unlikely to change.
As a normal user, on a Windows box, if you log into say a corporate Microsoft 365 account with your corporate credentials that device may get managed by the domain (pending any admin approvals needed on the management end) in some fashion because by default the local user/MS account user is a local admin and the services and processes that handle all of this run as SYSTEM thus the user has the authority to delegate that authority to remote management at-will.
Like, this is all basic stuff for BYOD and MDM policies if you've worked anywhere with a halfway competent IT staff. OP didn't read the fine print probably. Wouldn't be the first parent to not do so and freak out over nothing.
The parent owns the device and would have the local admin account. They aren't joining the device to a managed domain where something like GPO would be relevant (unless configured by the parent, naturally). The student would only have a non-admin local account, and would be incapable of granting device administration privileges to the school. The school could still manage their browser profile, of course—if the browser itself is actually signed in to the school account, which is something you can disable while still logging in to the account on the web—but they would have no access to or control over other user accounts or anything else requiring local admin privileges.
This isn't to give them extra credit. GoGuardian is still spyware and you should be, at the very least, wary of it if you have a kid with that software running around. But this behavior is consistent with the design of ChromeOS and isn't shocking or special if you've been paying attention to what ChromeOS has been built for over the last couple years.
Most companies either choose not to implement any of this, or simply do not know they can implement this. Do not sign into your personal devices with your work account on anything but an isolated browser (modern Windows has a sandbox built in!) or you might discover the hard way what kind of possibilities remote AD allows for.
Windows does prompt you to accept that the account can manage your device, but so does ChromeOS. Denying MDM may cause the login to fail if they automatically rescind any tokens that don't get MDM access on your device.
Having said all that the default will be for most school accounts… all or nothing. Don’t allow them to manage it and you won’t get in.
Fundamentally, authority cannot be delegated authority that you yourself don't have. I can agree to a contract promising to do some particular work, because I have the authority to direct my actions. I cannot agree to a contract promising that you will do some particular work, because you haven't granted me that authority. I cannot grant to another what I do not have for myself.
With regards to user permissions, a non-administrator doesn't have permission to monitor another user's activity. Therefore, they cannot delegate permission to a third party to monitor another user's activity. That this is possible means that ChromeOS has a fundamentally flawed model of user permissions.
And that's the problem. Signing onto a remote account is a request to access a remote resource, and should not be interpreted as granted the remote actor control over local resources. That Chrome OS works this way implies that Chrome OS is fundamentally flawed.