I think the overarching point is that MinIO doesn't understand their own license. MinIO can't retaliate at will, except by suing. It also shows that - as it has been since the inception of the AGPL - nobody knows what the actual obligations are. MinIO seems to believe that interaction with MinIO, including calling the API, makes your code subject to the AGPL too. They say as much on their compliance page.[1] This is the opposite view of someone like MongoDB, who used to have their software AGPL licensed, but explicitly made their clients permissively licensed, because their expectation from the AGPL was that it is not infectious across process boundaries.
MinIO has taken this to other extremes, including believing that your config file for MinIO is subject to AGPL. Even if you assume that an implicit dependence on an API is making the calling code AGPL, MinIO has the least strong claim for their service being infectious, because their API is mostly a reimplementation of S3.
This is like the "are Java APIs copyrightable" case all over again, except the people who are threatening legal action didn't even invent the API.
[1]: https://min.io/compliance
"When MinIO is linked to a larger software stack in any form, including statically, dynamically, pipes, or containerized and invoked remotely, the AGPL v3 applies to your use. What triggers the AGPL v3 obligations is the exchanging data between the larger stack and MinIO."