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.
For example I did a stint at a F500 company where 1) a data engineer did not know how to use multiprocessing to parallelize a multi-terabyte S3 upload 2) an internal tool that fired off hundreds of network requests did not use concurrency and hence had 30+ second latency 3) a certain other team was dumping hundreds of terabytes of logs that nobody even knew the schema of into S3 automatically, and none of it was ever touched. Also seen: "data scientists" who did not know Python and executives that spent more time talking about Scrum than any concrete execution.