I agree; a big part of the problem is that the whole concept of what an API is and what it does has really grown in the last 40 years. The original IBM PC BIOS exposed an API but it was far simpler than the Java API. When we draw an analogy between a large industrial machine and all of it's levers and switches and buttons and the interrupt calls on an IBM PC BIOS, the analogy seems somewhat reasonable. It certainly feels like we're straining that analogy when we apply it to the Java API.
Even so, the Java API is clearly documented and publicly available and anyone can look it over. It's clear that it provides a contract to the software developer saying things like "if you give me this data when you call this method, I will give you data that looks like this in return". The idea that an API is a contract, I think is sound and the analogy holds water, in my opinion.
Is there really nothing creative about writing an API? Well, I think that's an arguable point. When you drive a car you steer a wheel and when you type you press buttons; it's arguable that these are simply obvious implementations that many people might independently develop on their own. It's mechanical and, perhaps, lacking in creativity. But the Java API? Some portions, for sure, are obvious: any collection of things has a "length" method. But someone did come up with a plan for managing the namespaces and the package names and some packages have APIs that are pretty clever and, perhaps, reveal true creativity.
Still I'm against protecting APIs from third-party re-implementation. I did not find Oracle's arguments at all compelling and, in my view, that was really their job here. Instead they pretended that this idea of an API as a contract anyone could re-implement was totally alien to them and that struck me as a bit dishonest.
I'd like to see a more compelling argument before we upend how we thought APIs worked for the past forty years.