I agree with not introducing abstractions prematurely, but your suggestion hinges on the design of the S3 client. In practice, if your code is depending on a library you have no control over, you'll have to work with interfaces if you want to prevent your tests from doing I/O. So in unit tests you can pass an in-memory mock/stub, and in integration tests, you can pass a real S3 client, and connect to a real S3 server running locally.

So I don't see dependency injection with interfaces as being premature abstractions. You're simply explicitly specifying the API your code depends on, instead of depending on a concrete type of which you might only use one or two methods. I think this is a good pattern to follow in general, with no practical drawbacks.

Yes, this is absolutely dependent on the design S3 client.

The reality of development is we have to merge different design philosophies into one code base. Things can get messy. 100% agreed.

The approach I advocate for is more for a) organizing the code you do own, and b) designing in a way that you play nice with others who may import your code.