Unless you are a small shop and are doing all the building for each piece of your integration and have a great deal of experience - you can easily make mistakes like this. The point of my post is to illuminate the lack of data visibility on an issue that shouldn't exist. One of the biggest problems I could see would be someone internal such as the admin or someone with access to an admin level account wanting to download information or change/delete information without a trail leading back to them. The company would have no way to determine who was making those calls or even which IP address it really was coming from.
You are right, the authentication does get logged, but all it stores is which account logged in and which IP address they think it came from. Also, in some cases you will see what type of connection or client is connecting but for an API that is very infrequent. So in the case of these calls, and many others you will just see the IP address (that salesforce thinks it was) and the username. If this information doesn't stand out itself as incorrect then you wouldn't know that those calls were the offending ones.
Yes I agree, however that will not stop someone from changing or introducing information or deleting information into your environment via API.
There was no damage, there were calls that none of our APIs were making from an IP address that is not ours. When that occurred and we could get no more information on our own about these calls, we challenged SF Tech support to identify them. The only data they could get is the same data we could see. I used Github as an example as one of our lesser skilled engineers did post login details publicly on Github but realized his mistake right away so we could change the login credentials everywhere they were used. That was for a different account however it could happen again, even posting that data internally gives means for it to spread externally from one of many hands, not all in your personal control.