HTTPS web service switched to HTTP. What can go wrong?
You are right, the regression to HTTP is pointless.
Note that all your points apply to one particular kind of attack, where the adversary is able to access the data transport between client and server. That could be the owner of a WiFi hotspot or your ISP acting as a man-in-the-middle, who sits in between you and the server. This can be hard to accomplish for a remote attacker, but is particularly easy on a public WiFi.
What HTTPS adds to HTTP is secure data transport. The web application itself can be completely fine - if you are communicating over an unencrypted channel, the attacker will be able to read, modify and inject arbitrary data into your requests and the server responses. With a captured session cookie, it will also be possible to impersonate you for as long as the cookie is valid.
What the attacker cannot do is take over your Google account or reauthenticate with Google at a later point. This is because the authentication with Google always happens over SSL and the granted token expires after a given time.
So the situation is somewhat better than capturing your credentials straight away. However, as you said, an attacker would still be able to take over the session and perform any action on your behalf.
I would raise the following question:
What's the point in having authentication in the application?
If all the page contains is public content and verifiable in an outside way (eg. a debian mirror, where packages are with PGP) and your users don't mind a third party scrutinizing what they visit, the page might not need https. But not a login either.
Common reasons for requiring authentication include:
There is some data that the user can only read while logged in
A registered user can send messages to other people
It allows the user to gain reputation, by maintaining an identity that only used by him
The account can receive some benefits obtained outside (such as accessing paid content)
All of them are defeated by using http instead of https in the communication, as well as almost any other reason for inserting a login. Regardless of the fact of the password not being exposed (which admittedly would be even worse).
Some time ago, the price of buying the certificates was argued, but nowadays there are several CAs providing certificates for free.
† Nitpicker's corner, there are a few, extremely rare cases where the security isn't compromised by this. An example is Mega, which loaded some common javascripts though http, but a https-loaded script verified their hashes before executing them. Fragile and more complex than setting up https everywhere. Don't try this at home, kids.
Your credentials are safe, but Session Hijacking might happen
One possibility could have been an attacker might have done a SSL Strip attack while acting as the Man In Middle, If that happens the HTTPS website will be served as HTTP to the victim. But as you have confirmed with the website that they have done it intentionally, so this possibility is striked off.
Now, Google uses oAuth2, so the handshake with Google will be over HTTPS & you will be redirected to your website over HTTP after that (it happens the very same way with https://security.stackexchange.com/ while you use your google account). You website would have generated a session token after oAuth. The risk HTTP posses in this case is an attacher can very easily hijack your session and surf the website pretending to be you