If the table changes, the view doesn't change, this could cause you issue.
So you had this table
CREATE TABLE Table1 (
You create a view over this.
Then you add a new column
ALTER TABLE Table1 ADD DOB DATE NOT NULL
The view still thinks it has ID, Firstname, Lastname.
You try to insert into that view giving it ID, Firstname, Lastname, DOB it will fail.
But then say you wanted to change the size of the VARCHAR columns
ALTER TABLE Table1 ALTER COLUMN Firstname VARCHAR(10)
The view metadata still thinks the column is a VARCHAR(50), but the table is now actually a VARCHAR(10).
Try inserting a string longer than 10 and you'll end up with truncation issues.
So point 1 is mute, if you change the table you must also ensure you refresh the view(s) that those tables touch otherwise you end up with all sorts of behaviour issues.
For a security perspective yeah having an abstraction layer is good, as you move the security else where, but you need to ensure the abstraction layer keeps up with the metadata of the underlying tables.
Not saying views are bad, just watch out for when the metadata changes, may be one to get into a habit of running "sp_refreshview" to update the metadata when you change the table definitions to ensure things are always aligned with the base tables.