Why WordPress use a column prefix? I'm trying to learn some basic database design through open source projects.

And look into the WordPress database schema, the posts table for example, you'll find something like this

post_author
post_date
post_title
post_content
...
...
etc.  

We're already in the posts table, why not just author, date, title, content? Is there any reason? Or just because WordPress is too old..?  

(The same in other tables. In users table, will find user_login, user_pass, user_email, etc.)

I found many people say that using a column prefix is a bad practice, so, just title, content... will be a better design?
There is more than one school of thought concerning the naming of columns or fields.  

One school of thought says that the name should express the intent of the data being conveyed even if that name is separated from the context where it is found.  Thus, a name like post_date or another name like comment_date tells the reader not only that this is a date, but that it's the date of a post or a comment.  

One advantage of this convention is that it makes it easier to maintain a data dictionary, where the full definition of each data element is to be found.  It's easy to navigate from a column name to the corresponding data dictionary.    

This convention was apparently used in Wordpress.

Another school of thought says that the name of a column or field ought to convey the intent of the column or field in the table or record where it is found,  according to the role it plays in that context.  Thus,  date merely tells you that it's a date,  but post.date presumably tells you that it's the date of a post.  And comment.date would tell you that it's the date of a comment.

There are advantages and drawbacks to both schools of thought.  The most important thing is to be consistent, once a naming standard has been agreed to.  A naming convention that is sometimes disregarded creates pitfalls for the maintainer.  

One drawback to the second convention is that FKs can generally never have the same name as the PKs to which they refer.  Another drawback is that, if there is a context, such as the forms manager,  in which "date" is a reserved word,  now you're forced to violate your own convention.

One drawback to the first convention is that it makes it awkward to express a reflexive relationship, one in which an FK refers to a different row in the same table.  Take, for example, "supervisor_id", a column you find all the time in employee tables.   You can't give it the same name as the PK that it refers to, because then you would have two columns with the same name in the same table, and that's forbidden.  So now you're forced to violate your convention.