Someone said something like "Always do what makes sense". I vote for that!
It never stops amazing me how "solutions" are discussed as if they would work universally. Most of them, don't! Most of the time, nobody even asks if we're talking about an OLTP environment or a data warehouse?
RBAR SSIS may work for you, or not. Let's say you have a data warehouse that you update at night, and it is only in use during the day for custom reporting. What's wrong with SSRS (RBAR) during the night in this case? Nothing. Quite the opposite: when done right (as part of a framework), when you come in in the morning and something went wrong, you know what the error was, it's in your email, you know how many rows were written before it aborted, and, after fixing it, restarting the package will automatically delete the rows written before the error and start over, as well running subsequent packages that are waiting...
What's wrong with RBAR at night? The answer is, it takes extra time and resources to execute. Nightly runs have to finish before business opens for the day and there's only so much time and so many resources available.
As for the suggestion that RBAR is the only way to know what went wrong at the row level, nothing could be further from the truth. Even BULK INSERT has switches that can be set to allow an unlimited number of errors and to sequester the bad rows with an explanation by column as to why each row failed while still allowing the rest of the run to complete. And SSRS, SSIS, or any of the other 4 letter words in SQL Server don't need to be RBAR just to report what the errors are.
To tell the truth, though, there should be 0 failures all the time even if the data is bad because the data should be imported into a staging table, prevalidated, and marked as either good or bad and what the reason is. A failure shouldn't ever find you. You should find the failure before it happens especially when it comes to the act of loading data.
This is all a part of what I've been talking about. People don't know what they don't know and resort to RBAR because that's what they know. For people in the business of doing the things you mention, they should buckle down and learn the tools so that their processes can work in a timely and resource thoughtful manner. And, you can't make a resource run 12,000% faster by throwing hardware at it. It takes knowledge and practice. I recommend people spend some time getting a whole lot more of both before succumbing to RBAR and calling it "done". Without such knowledge, you don't actually have the skills to determine what actually "makes sense". 😉