That page describes exactly what is happening:

The network administrator can adjust the DNS configuration for www.google.com to point to our NoSSLSearch end point. For regular http traffic, the user will see no difference.

We will not serve SSL search results for requests that we receive on this VIP. If we receive a search request over port 443, the certificate handshake will complete successfully, but we will then redirect the user to a non-SSL search experience. The first time a user is redirected, they will be shown a notice that SSL has been disabled by the network administrator.

Google provides an option for network administrators to disable SSL searching on their own networks. It doesn't involve paying Google. You can see in this thread that filter manufacturers and their clients (schools, etc.) were the motivation for this feature and they'd simply block services that didn't allow filtering if the feature didn't exist.

I really doubt that anyone in the western world would even attempt blocking Google - the blowback would be immediate and huge if regular people were banned from using Google on their computers.

Wow, that is very disturbing. Talk about intentionally shooting yourself in the foot, security/privacy wise.

It seems like that technique no longer works.

The end of the thread (from earlier this year) seems to indicate otherwise.

A Google employee addresses this: https://productforums.google.com/d/msg/websearch/1l2KMUfgyo4.... Apparently visiting `nosslsearch.google.com` directly does not have the intended effect, but setting up the CNAME record does.

I tried it myself before making the comment and it did not work, but perhaps that was because of HTTPS Everywhere.