I know the comment came from a good place and you meant well. The situation you describe of “developers working on the wrong thing” can and sometimes does happen, however, as a manager the effective way to handle those situations is to address the root cause. Is it because the task is too big, not enough details, is it too early in the project that the requirements haven’t really surfaced organically? You want your team to be autonomous, you want to empower your team to make mistakes and at the same time actively minimize the chance for mistakes by greasing “things” so people around you can be more effective.
There are few things as negative for a team performance as an insecure manager that needs to be making tactical decisions for the team as if developers were little kids.
I agree that a manager shouldn't micromanage to the point that they believe developers cannot be productive without their manager physically present, but that is not what they were talking about. The comment isn't about the developer needing their manager's insight or guidance, but about the developer needing the expertise of the rest of the team, which they will not have access to at nights or on the weekend.
I think in response to the OP, the user identified the "problem." I've worked places where the above was the norm, and other places where if ticket showed up in front of a developer and required additional clarification (from QA or other developers) this would be covered in detail during sprint retrospectives, with the intention of making sure that the team works hard to make sure that this never happens. It can blow estimates not only for the given task, but can have cascading effects as well.
That said, this might not be easily attainable or the best practice for all organizations, but I think I prefer better processes over evening and weekend work.
I for example seem to almost need this kind of rhythm. Yes it is spiky and sometimes a bit chaotic. But also very intrinsically motivated, which can sometimes lead to high impact solutions.
A good way to deal with this tradeoff is writing more text and less code. Text which is off-base is much more valuable than code that does do wrong things or things in a wrong way.
But I have to say that I work alone or in small teams, which requires less technical coordination.