I have often mistaken these two terms and so have others. I find people quite often use one when they actually meant the other. For those, who use the terms correctly, this post doesn't have anything for you.
I used to think hierarchy is a bad thing and promotes bureaucracy. So much so that I started assuming one implies the other. My current stand on these two terms is a little different.
I feel, hierarchy inherently is a good thing and it doesn't necessarily promote bureaucracy. Bureaucracy isn't a bad thing either but it does become bad when it is out of place. It might make sense to have bureaucracy in a non-creational environment. Places where maintaining a system or a business process is the objective, it perhaps is a good idea. Transport it to a creational environment and you suck the life out of the team. A lifeless team cannot create much.
Coming back to hierarchy, the reason I find it better than a flat structure is because it helps you define your constants. If someone is at a level, you can make certain assumptions about her. An example would be, if you have developers ranging from 1 year in industry to 20, all marked as developers, there is hardly a parity when you have to address (it can mean various things here, work allocation, training requirement, staffing for a project...) a group of 'developers'. (Here I don't intend to mean that years define expertise, but in a normally distributed environment, more experienced people have a better chance of performing and knowing more than saplings. In case new folks are smart they will jump the levels faster). You never know what can be assumed for a developer. But, if we have levels, there will be a benchmark understanding based on a person's level.
In an organizations that boasts of having a flat structure, it isn't impossible to find a developer who doesn't know what version control is and another one who would have written a version control software. Both will be tagged developers though. It is equally likely to have an organization with many levels and still no communication barrier despite the number of levels.
If I see an organization that boasts of a flat hierarchy, I am going to be, if not highly suspicious, very cautious about it. At the end, it's all about people making the group to define their environment no matter how you structure it.
trial comment
It was pretty interesting reading your blog on hierarchy v/s bureaucracy. But I think you are confusing hierarchial, flat and functional structures. When you talk about developers with experience in coding and experience in version control all tagged as developers and the absence of distinction between them and hence feel hierarchy better, you are comparing apples to oranges. Hierarchies have many levels of management, you don't need a hierarchy of programmers and version controllers. What you need is functional structure to distinguish specialities. So you could have a flat organisation, CEO, Managers, and then functional teams like developers, web designers, version controllers who work together as their jobs are interdependent.
Thanks for going through the blog. Perhaps there is some part which I haven't explained very well.
"developers with experience in coding and experience in version control all tagged as developer"
This is not the issue as I see it. This was an example. I would expect any one year experience developer worth his/her salt to know what version control is. It was just used as a tool to draw a comparison between a newbie vs a seasoned programmer (somebody who wrote a version control - again I don't mean this literally, hardly anybody does that).
So, to summarize I didn't mean dev vs version control know-er as two different competencies, they are not. A developer is supposed to know version control among many other things.
Web designer - I agree would be a different competency and I would like to see layers within them as well.