Oracle's argument isn't legally circular or anything like that. It's actually very strong, which is why it's problematic: the industry status-quo consensus that you can't copyright APIs has no obvious basis in copyright law beyond the notion that you can't copyright "facts".
Is an API a collection of facts? I would hate to be a lawyer tasked with arguing this one in front of the Supremes. Programmers sweat bullets over API design, an API is very obviously not a mere collection of facts, it's a creative work. Copyright law protects creative works. Hence, Google's problem.
An API is not a mere collection of names either. The Java API is defined by the specification, which is contained in the JavaDocs. Thread safety rules, when callbacks are invoked, what sub-types can be passed into a parameter, all these are a part of the API as well. Strip out the source code of the methods but leave the types, prototypes and JavaDocs and you have the Java API - it's been done and the result is still huge.
Google's point is essentially one of convenience; the industry has never recognised APIs as copyrightable before and shouldn't now. This is not a legal argument at all so I am mostly expecting Oracle to give them a solid thrashing, because the SC is meant to interpret existing law, not simply agree to whatever one of the parties thinks the law should be. And other than declaring API reimplementation to be fair use, there's no obvious legal escape route to make APIs non-protected.
It's thus interesting to consider what happens if or when Oracle win. In the short run a lot of disruption, especially to projects like Wine and maybe WSL.
In the long run it's harder to say. Something unprotectable would have become protectable. We might see, for example, the birth of companies that specialise in nothing except API design. Today such a company would be unviable because there'd be no way to protect or own the results. You can imagine that this would occur in the same way that specialised agencies do graphics design, translation, logo design, API implementations, etc. This might lead to higher quality APIs across the industry: a difficult to anticipate side effect of expanding IP protection. It would also presumably reduce competition as it became even harder to compete with lockin via reimplementation of APIs. However, doing that is relatively rare today. I can't say for sure that the (small) loss of plug-compatible competing implementations of products would be worse than a hypothetical increase in API quality from allowing specialisation in it.