It didn't use to require a payment method/billing account and the change appears both for compatibility reasons, as the deployment method now relies on a service that does require a payment method, and for fraud reduction which they claim they have evidence for when requiring a payment method.
The way this works with Google App Engine is that they will issue a charge of $0 that you authorize on your credit/debit card mobile application, so it's not just a Luhn credit card number check.
I do not have evidence of how effective it is but, intuitively, it may increase the effort for fraudulent use. It is "KYC by proxy". It is also harder to get a credit card than it is to create a bogus email address in case you have free quotas, and in case there's a pattern of fraudulent usage from an account, they can use the credit card number as a selector to see which accounts are linked to that number and block them, which is harder to do only by email for you have to use more sleuthing and selectors to link accounts to an entity.
If you think of acquiring good users/making a sale as a conversion process in which you try to prevent people dropping off the process or abandoning a cart and you try to increase the conversion percentage at every step, you can think of this effort as an "anti-conversion" process in which you try to reduce the percentage of fraudulent users making it to the next step, you weed out and filter as many as you can at every step of the process.
There will be people who will make it, but they'll leave additional trail and pieces of information you can use later to find them.
One unrelated anecdote from a mistake Reddit made at some point was that they stored passwords in plain text. From a security perspective, this was bad, but the anecdote was that they used this to find and weed out a lot of fake accounts because they all used the same exact password.