A case against “Don’t add unneeded context”

I have seen the “Don’t add unneeded context” in yet one more place and I will put a short case against this.

In brief they say – this is bad:

class Car
{
    public $carMake;
    public $carModel;
    public $carColor;

    //...
}

And this is good:

class Car
{
    public $make;
    public $model;
    public $color;

    //...
}

I say the “unneeded context” which In this case I will call a prefix should stay specially on ActiveRecord classes because:

I find extremely useful the properties to be named the same way for the sake of traceability from the front end (field names in forms) all the way back to the database column names
because of the above not having a prefix and having just column names like “color”, or “name” (think of user_name, role_name, bank_name) and having of join of three tables like “users”, “roles”, “bank” and forgetting to set aliases will produce wrong results. The last selected table will overwrite the names of the rest. Consider having not just three tables but a join of 10 or even more… with tens of columns each… It is a lot of typing to alias many things. And if there is “SELECT users.*, roles.* … ” then things go really bad. When there are hundreds of returned columns overwritten values go unnoticed.
In regards to the front end – in a form where in one go (one transaction) we need to create a User and a Role we will need to add prefixes to avoid collision of the “names” (role_name vs user_name).
Searchability – if I need to find out where the user name is used I can search for “user_name” while if I dont have the prefix I will need to search for “->name” which will return also Roles objects, Banks objects…

One rule I follow is that the foreign keys remain unchanged – in the Users table the user role ID will be named “role_id” (FK to roles.role_id), not “user_role_id”. FK have different name than the column to which they point only if it is not possible otherwise. Like a tree structure where we have category_id & parent_category_id.