... encapsulate complex query ...
Yes, Views can do that, calculating "dynamic" values on the fly (like
age from a stored
date_of_birth or an Order total from the individual Order Lines).
... Handle security related issues like permission ...
Not so sure about this one.
Views can be used to restrict access to tables - only giving "read" access through a View and not giving permissions on the underlying table(s).
Views can also get you things like Row-based-Security, where a User can only access their own data in a table based on some column.
I would hesitate to put "Views" and "Permissions" together directly as concepts
Which User or Group has access to which database object(s) - i.e. Database Permissions - remains a separate thing.
... simplify supporting legacy code.
Maybe, maybe not.
It depends entirely on the legacy application.
In some cases, trying to "inject" Views into the code can make things a whole lot more difficult.
I have a single table and different types of user can only work on different column of the table. Is it ok to use view to manage permission in this scenario ?
Each community of Users would be given permission on a View that meets their needs and wouldn't even know that the others exist.