Compatibility with GPL in this case simply means a software distributed in a compatible license like MIT can be combined and distributed under GPL [0].
>On your second point: Can't they argue that they implement against an API, which could be provided by non-GPL software as well?
I don't think that is reasonable. A GPL program is specifically named in requirements.txt and imported. It's essentially the same as dynamic linking, that is no more than naming a program and using it's API. If this argument was valid one could also argue it's possible to modify a dynamically linked binary's rpath (can be easily done with patchelf on GNU/linux) from a GPL library to a non-GPL one so dynamically linking a library would never require you to do abide to it's license, which is obviously untrue [1].
>On your second point: Can't they argue that they implement against an API, which could be provided by non-GPL software as well?
I don't think that is reasonable. A GPL program is specifically named in requirements.txt and imported. It's essentially the same as dynamic linking, that is no more than naming a program and using it's API. If this argument was valid one could also argue it's possible to modify a dynamically linked binary's rpath (can be easily done with patchelf on GNU/linux) from a GPL library to a non-GPL one so dynamically linking a library would never require you to do abide to it's license, which is obviously untrue [1].
[0]http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean
[1]http://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic