Besides being a micromanager's dream, the whole concept of "blockers" in agile/scrum is just a way for companies to blame developers for the company's lack of resources and poor strategy (i.e. the team is too small for the amount and complexity of tasks, so there is no time to properly define and break down tasks, focus is on quantity/output instead of things actually working, management encourages a lone wolf mentality, etc.).
If you don't care about delivering broken software and having high engineer turnover, scrum is just fine.
In my experience, when you see scrum, you will see an over-bureaucratic company with way more managers that engineers and, usually, those managers (call them product owners, project managers whatever) are the ones calling the shots which leads to all sorts of problems due to their general lack of technical knowledge and overfocus on "deliverables and customers needs".
And don't get me wrong: customer needs are the priority in every company that sells software or provides SW services. But one thing is what customer needs, and another is how to provide it to them.
More times than not, in those places, we ended up redesigning a feature in the middle of the development because it was designed by POs and other ilk only looking at customer needs, so that design didn't fit the system.
If you don't care about delivering broken software and having high engineer turnover, scrum is just fine.