Take the uploading to s3 point. If you are saturating your network... going multithreaded will do nothing. If you are not, find out why.
The other examples are also lacking a lot of details. 30 seconds of latency can be bad, of course. But so can adding concurrency to a team that doesn't understand it well. (Really, this one sounds like it just needs more context. I'd normally push to remove extra calls moreso than jumping to concurrency. But, each has its place.)
Edit: And the logs... this is just a result of not putting cost as a tracked item for teams. Too many folks fall afoul of a hoarder mentality when it comes to logs.
Similarly, an otherwise great developer can be horrible in a team that doesn't know how to use them.
It might also be that it's not worth spending effort on speeding up some script like this. How often does it run?
Do these 30 seconds matter? Maybe they do now but they didn't in the beginning, but then that's ok, too, and you refactor.