Most places I've worked, there is a clear separation of roles between the Product Owner (whose job it is to handle the business case, gather requirements, understand the "why", and decide the "when" and "what"), and the engineering TL who is merely in charge of "how".
At a few places, the TL does it all: business case, requirements, project motivation, schedule, AND the implementation. A lot is asked of that person, but it results in IMO better coordination and execution, because it's not a constant battle between "engineering vs. product". Well, there is a battle, but the battle takes place entirely in the TL's head, so it's faster and less visible.
In order to do it the second way, you need to hire engineers who also can manage the business/requirements side of the project. These people are significantly harder to find than engineers who just read a requirements document and implement it.
That's correct and that's the point: the bad scrum situation is sometimes in place because the TL does not do it all, either because they don't want to or is not able to.
Sometimes, it is because the owners or the managements do not let them to. Sometimes, it is because when the owners or the managements gave them more opportunities, the engineering TL did not use these opportunities and the owners or the management had to fill the gap.
As you said, taking these responsibilities is difficult for the TL and is asking a lot, so I don't think it's fair to expect it to be done systematically.
On the other hand, on my own experience, it is not very difficult to understand the technical aspect. It does not mean "being able to code", it just means "the devs explained the situation and I understood it". My experience being in the middle is that devs are usually worst at understanding the business side than the business side at understanding devs. So I really think that it's unfair to say there is only two ways: either the TL take everything in charge and the decisions are good or they don't and the decisions are bad because non-devs are obviously idiots.
At a few places, the TL does it all: business case, requirements, project motivation, schedule, AND the implementation. A lot is asked of that person, but it results in IMO better coordination and execution, because it's not a constant battle between "engineering vs. product". Well, there is a battle, but the battle takes place entirely in the TL's head, so it's faster and less visible.
In order to do it the second way, you need to hire engineers who also can manage the business/requirements side of the project. These people are significantly harder to find than engineers who just read a requirements document and implement it.