This answer made more sense prior to the questions 3rd edit.
Coupling and cohesion concerns can get you pretty far here but shouldn’t be considered in a vacuum.
I know this isn't meant as perfect example code. But it would be irresponsible not to call out the issues. As I do I'll try to not let that distract us from the point of your question.
Firstly, am I wrong in assuming that just asking about cohesion and coupling with regards to this code is enough to motivate this refactoring
This isn't a refactoring. A refactoring has the same behavior. The second listing has a magic 5 in it that seems unrelated to the first listing.
I do see an overall theme of applying doSomeBusinessLogic() in a loop over some things. You've changed how those things were expressed as arguments to this function and how they are acquired.
Choosing to express the same idea with fewer arguments could easily be argued as motivated by coupling concerns. Data coupling is a form of coupling (one of many).
Second, as far as I understand it the code in the first snippet is cohesive; there's no statement/expression that isn't providing value towards the result of the function - it's all related to the function. Some would say that the SQL statements and ConfigurationManager are different concerns, but I don't understand that logic. Isn't a function always going to have this? It's the intent of the function that drives what cohesion means for the elements of the function.
Here we're running into a problem with names. Your example has dead poor names. "But it's just as example" doesn't cut it because the names are critical here. Cohesion operates at different levels of abstraction. In any application that works there is a level at which you could argue everything is cohesive because it does what it's supposed to do. Which misses the point.
We want cohesion all the way down. What level we're at is easiest to spot from the name. For example, the exact same toys that are cohesive in a "toy box" are not cohesive in a "doll house". So the name is important.
You gave us, "doSomething()". Sigh.
Maybe we can work with "BusinessLogicClass". A good name tells you what does and doesn't belong inside. So what belongs here is logic that supports business rules. If we assume doSomething() is a poorly named business rule it makes sense to focus on logic from the business and not from the tech decisions. Like "use sql".
That explains much of this change (still no explanation for the 5).
It seems like any dependency which isn't passed in is going to be considered strong coupling
I consider that hidden coupling. Yes eventually decisions have to be made. But parameterizing gives those decisions a clear place to be made. It also clearly expresses needs. It doesn’t eliminate coupling. It makes the coupling obvious.
or should I be using other principles, asking other questions?
Certainly there is more to understand here than simply cohesion and coupling. I've already gone on about naming. The principles are sign posts that warn you of hard to see costs. The problem with trying to focus on one principle and ignore everything else is the one principle becomes nonsense in that vacuum. Sorry, but there is no silver bullet here.