This is a narrow view, but one example is that if you're using JSON and your API response looks like this:
[{id: 1, …},…]
Then you can't easily add pagination without changing the structure of the response. Whereas if you have something like this:
{results: [{id: 1, …},…]}
then you can add in whatever other properties you need and this change can be made without immediately breaking any existing applications. Of course, it's still true that you'll have to rewrite the frontend to actually implement pagination, but it does do something for backward compatibility. You could probably still have old versions of the application at least display the first page of results without changes.
That's the best interpretation I could come up with as well.
I think the general idea is to leave room in distributed APIs to add metadata later. It's not really just about potential pagination, but leaving yourself a way to add/change functionality later without updating all the clients in lockstep with the server (always awkward and there's never a way to pull it off 100% cleanly).
In this case, it would often be better to make a breaking change than to have a client that thinks it's fetching all the items but isn't. For a frontend application sure, it might be fine that the user only sees one page, but it might also be a big problem. For backend APIs you absolutely don't want to add a new pagination mechanism that clients don't know about.
[{id: 1, …},…]
Then you can't easily add pagination without changing the structure of the response. Whereas if you have something like this:
{results: [{id: 1, …},…]}
then you can add in whatever other properties you need and this change can be made without immediately breaking any existing applications. Of course, it's still true that you'll have to rewrite the frontend to actually implement pagination, but it does do something for backward compatibility. You could probably still have old versions of the application at least display the first page of results without changes.