I guess you could say that then you never have to qualify the column name in the query (as they're unique across the system). It's a pretty crummy reason to do it though.
More likely it's just that someone decided that was how they were going to do it one day and it stuck.
I worked on a system where all tables were prefixed with "tbl_" - even when they were often views and not tables at all....
If you are using PHP without a framework and mysql_array_assoc, there can be collisions / inconsistencies / problems in joined columns that have the same name. I've run into it a few times. Most decent systems don't choke in that case, but there are cases where it's simply easier to prefix column names instead of writing AS everywhere. If you're working with really long SQL queries generally it can also help make things more explicit.
I don't do this usually but I have run into a couple of occasions where it would have helped out.
When you do a SELECT * and with a join or two, you get the chance of field name conflicts which can cause logic errors. You either have to alias the conflicting fields, specify each field you want on the select, or prefix field names so they never conflict.
I've used this myself in the dim and distant past (there is still code in my area of responsibility that shows signs of it).
I find the much better method is to be strict about table names and aliases:
1: Always specify the table name with field names. Even if there is only one table in the query (if the query changes later to draw in data from another table, you don't have to go back and add the table references if they are already there). As well as avoiding name conflicts which will raise errors, it removes certain silent fails that are possible with correlated sub-queries when you don't explicitly note the intended scope by naming the object a column should be found on.
2: Always specify a short but meaningful alias for every object referenced in the query/view (such as "kpi_fact_definition AS kfd"). It makes the code more readable when every column reference has "<table>." prefixed.
2b: All aliases should be unique within the query/view even if the same object is referenced more than once where the scope of each reference means the names/aliases would not conflict. Also try to avoid using aliases that are visually similar (visually similar aliases can lead to typing errors being able to hide in plain view).
3: Make sure that all tables/views have meaningful names, even if they means them looking overly long. You are going to give them short aliases when you use them anyway.
