An argument for viewing them as copyrightable and then making copying for compatibility OK under fair use or merger would be to avoid complicating copyright law.

A good example of this kind of thing can be seen in how copyright law deals with executing programs. Suppose you have a copy of a copyrighted program on your hard disk. You tell your computer to execute it. To do that the computer reads the program from the hard disk and writes it into RAM.

Most people would say that a copy of the program has been made in RAM. That naturally leads to the question of the copyright status of that copy, and what, if any, permissions you should need from the copyright owner in order for making that copy to be legal.

It seemed apparent to most (including the majority of people in charge of writing copyright laws...) that if you are the lawful owner of a copy of a program you should be allowed to make a copy of that program in RAM in order to execute it. The question, then, is how to fit that in with copyright law.

There are at least a couple of ways to approach this.

1. Define it as not being a copy, and therefore out of scope for copyright law.

2. Acknowledge that it is a copy, but make an exception to the copyright owner's exclusive right to make or authorize making of copies.

The problem with the first approach is that it adds complexity to a layer of the law that it is really nice to keep simple. In law, like in many other fields, keeping the base simple and putting the complexity in upper layers leads to things being easier to understand, and easier to modify and fix without unintended consequences. It generally works out much better to keep the lower layers simple, especially the definitions of terms in the lower layers.

In the US they went with the second approach. They added an explicit exception to the copyright owner's rights that covered programs (17 USC 117).

A very similar argument could be made for APIs. 17 USC 102, Subject Matter of Copyright, is pretty simple:

Copyright protection subsists, in accordance with this
title, in original works of authorship fixed in any
tangible medium of expression, now known or later developed,
from which they can be perceived, reproduced, or otherwise
communicated, either directly or with the aid of a machine
or device.

It seems like an API would qualify under that. There is another part of 17 USC 102 that does put a limit on the part I quoted above:

In no case does copyright protection for an original work of
authorship extend to any idea, procedure, process, system,
method of operation, concept, principle, or discovery,
regardless of the form in which it is described, explained,
illustrated, or embodied in such work.

One could argue that APIs fall under this, but it is not at all clear what aspects of an API are the ideas, procedures, etc., and what parts are not. We'll end up having to contemplate the difference between a thing and the name of a thing.

It's the same problem as I described with copies on RAM. 17 USC 102 is part of the lowest layer, so should be kept simple, and so one can make the same argument that things are cleaner and safer by keeping an expansive interpretation of 102 and using fair use or something else at a similar level to authorize API copying for compatibility.

One of Microsoft's points in their brief when they asked CAFC to take the appeal was that this was the approach of prior courts that dealt with copying API elements for compatibility. They did not rule that APIs were not copyrightable. They instead found exceptions that limited the copyright owner's rights in the case of APIs and compatibility.