Why use typedefs for structs?

Question

in C (ANSI, C99, etc.), structs live in their own namespace. A struct for a linked list might look something like this:

struct my_buffer_type {
   struct my_buffer_type * next;
   struct my_buffer_type * prev;
   void * data;
};

It seems quite natural however for most C programmers to automatically typdef those structs like the following

typedef struct tag_buffer_type {
   struct tag_buffer_type * next;
   struct tag_buffer_type * prev;
   void * data;
} my_buffer_type;

And then reference the struct like a normal type, i.e. get_next_element(my_buffer_type * ptr).

Now my question is: Is there a specific reason for this?

Wikipedia says http://en.wikipedia.org/wiki/Typedef#Usage_concerns

Some people are opposed to the extensive use of typedefs. Most arguments center on the idea that typedefs simply hide the actual data type of a variable. For example, Greg Kroah-Hartman, a Linux kernel hacker and documenter, discourages their use for anything except function prototype declarations. He argues that this practice not only unnecessarily obfuscates code, it can also cause programmers to accidentally misuse large structures thinking them to be simple types.[4]

Others argue that the use of typedefs can make code easier to maintain. K&R states that there are two reasons for using a typedef. First, it provides a means to make a program more portable. Instead of having to change a type everywhere it appears throughout the program's source files, only a single typedef statement needs to be changed. Second, a typedef can make a complex declaration easier to understand.

I personally wonder if there is not enough benefit of having the separate struct namespace to sometimes not use typedef'd structs and since there are several C programming cultures around (Windows C programming has different traditions than Linux C programming in my experience) if there are other traditions that I am not aware of.

Then I am interested in historical considerations (predecessors, first versions of C).