It just more efficient if the BA has some technical skills. Even if its the creation of user requirements or creating issue tracking spreadsheets and the like.
One of my favorite examples is the sub draft complaint. One BA on a system to capture complaints, decided that if a user was writing a complaint, and ran out of time they could save it as a draft complaint. Then come back and finish it later. Then they decide that there was a need for hierarchy of complaints where the there were numerous sub levels of complaints and a master complaint. Then they decided all of these had to have draft complaint functionality. Then a list of complex rules about when a draft complaint, was submitted what happened to the related sub complaints still in draft.
In the end it was so complex no one could understand it. They dropped all of it, and had one complaint, and if you didn't finish it, tough we didn't store draft complaints at all.
Another guy didn't realize the user requirements, and the feedback from the user groups was completely at odds with the how the system actually worked, because they didn't understand it, and had created completely inefficient process because of this. The BA modeled all of this inefficiency and then was completely lost when it didn't match the existing system or the data relationships within.
These are the risks when a BA is too detached from the technicalities of the process they are trying to define.
You are right to say in that this is rolling up tasks better given to someone like a system analyst, or technical pre-sales people. But in reality these often don't exist and the BA has to be adaptable.