I think that's a bit too much. Nothing in that suggests that they are breaking anything in the HTTP specification. You're right that GET requests has to be idempotent, but the exchange from the single-time use code you get in email with the API token, is most likely behind a non-GET request (like POST). The HTTP server responds to GET requests with the static assets (HTML/CSS/JS), but then the static assets has JavaScript that calls the POST endpoint for the exchange.
At least that's my guess. I agree it's a bug on their side, and they should fix it. But I think it's more of a UX issue than breaking the protocol.
We found at least one scanning service to be fetching the URL with the user agent of a browser, and executing JavaScript on the page.
A lot of our user interactions could be simpler, but this sort of behaviour led to many things being put behind a "go" button.
I only wonder how long before scanners and search engines start clicking these buttons to activate content on the page so they can scan/index it.
Idempotent != side-effect free
Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. (RFC 7231, § 4.2.1)
!Idempotent != Reversal of changes
1. You open the link once = your account is verified
2. You open the link twice = your account is still verified
???
1. You open the link once = you're logged in
2. You open the link twice = you're presented with an error that the magic link has already been used.
So while I think what Outlook does here is wrong, what these webpages do is simply a bug that should be fixed and shows a lack of understanding of HTTP.