Something being merged into development means that it is 100% complete and ready to be deployed to production at any time. This means all QA and acceptance testing had to happen before merging.
1) A feature that's in develop may sometimes need to wait for something (QA, business validation, a go-ahead, whatever) to go to master, or 2) A feature that's in develop can ALWAYS go to master at any time.
In the first case, you can have feature X blocking all other features because it's in the same branch as them, which is the problem the GP is describing. In the second case, the two branches are the same, so why not just merge into master directly?
A feature might be stable as a standalone, but in virtually every software suite, features interact with each other. That is what develop is for. It's where all the feature branches meet and where any instability created by everything coming together is resolved.
Master, on the other hand, is the product of that successful resolution after all the bug fixes.
At my last job, we had a 'gorilla' that had to approve every commit, and it was his job to coordinate between the project managers and the developers as to what was allow to be promoted to prevent exactly the scenario you described. It also had the benefit of making developers describe each commit clearly so that the gorilla could understand the change, which made looking at the commit history some time later (months/years) quite a bit easier too.