In general, if no documented guarantee exists then you should assume there is no guarantee.
That's what I thought too.
If you are a developer and you link against a particular version of a library in Debian 9.1 and its ABI changes in 9.2, it's a simple task to rebuild it, and in fact that is what all reverse-dependencies of that library in Debian would themselves have to do. Not a big deal; as a developer you are supposed to deal with these issues and make it transparent to your end users.
Well, there are use cases that are not so simple. For example: I might deploy Debian 9.1 on an embedded machine sold to a client on the other side of the world. I have a system for updating my own software which is also deployed on that machine, but not the rest of the Debian system. Now, if ABI might change between 9.2, then I have no guarantee that if I test my software update with 9.2, it will be work as expected on the client's machine with Debian 9.1. However, building and testing my software with Debian 9.1 might be a problem. For example, the official Debian Docker images (
https://hub.docker.com/_/debian) are only provided for the latest point release. Finding older point releases from other sources is also not the simplest, and seems to be discouraged and not perfectly supported. See for example the notes here:
https://cdimage.debian.org/mirror/cdimage/archive/
Note that this use case requires that ABI does not change at all - not even in a backwards compatible way, because in that case I might inadvertently start using a new symbol introduced in a library in 9.2 which is not present on the client's 9.1 system.
For these reasons, I would appreciate if the documentation was a little more transparent about binary (in)compatibilities across point releases and security updates.
Best regards,
Jakob