The issue with this statement is that it is making a determination of PM responsibility and accountability based on roles that are or are not present. The presence of a BA role--or more precisely the presence of another individual with a BA title--is immaterial in determining whether or not the PM has any degree of responsibility or accountability in the development of business requirements. What matter is what is in scope for this project as should be indicated in the project charter, scope statement and description, and work breakdown structure. If requirements development is within scope, then the PM has responsibility / accountability for its development to specs. If there is another human on the project with the title BA, then that person has responsibility for its development, too, but the PM retains his/her degree of responsibility and overall accountability for this product as the BA would report--either matrixed or directly--to this PM.
The only caveat to the above is if the contract--assuming a seller and buyer arrangement--explicitly carves out this particular product from the PM's scope of work. Thus, the product is still in scope for the project but excluded via contract for the PM. In this case, the PM has a dependency for its development, and corresponding risks. Therefore, while not directly responsible for it, (s)he has skin in the game.
TL;DR: The presence of a BA is immaterial in the determination of PM responsibility and accountability.
Having done a bit more research here, I see what PMI has done. They have a newish (I have no idea when this certificate was created) BA certificate and, apparently, a BABoK. So in PMI parlance, there is a distinct swim lane between the BA and the PM. So in the business case flow chart, it appears that the problem identification leads to the requirements product which leads to the project charter and then to the PM. So, if you're studying for the CAPM or PMP, you need to learn it the way PMI has set it up. However, this is one of those areas that, in the real world, you'll experience something quite different in many cases. It's not that PMI is wrong here, it's that it is overly simplified. In many cases, the project charter can include the development of the business case and then the requirements. So just be aware of that as you progress in your career.