Comparing filters which are sent by WFS clients with a fixed views which are created into the database is not very reasonable for my mind. Both have their use cases and normally if WFS service is not made only for delivering the whole featuretype with plain GetFeatures the data that comes from the database are filtered further with WFS filters.
Geoserver tries to convert filters to corresponding SQL queries and in simple cases
"select sth. from table where property=x"
there should not be notable difference in the performance . With complicated queries it may happen that Geoserver queries more data from PostGIS than necessary and the final filtering is done on the server. That may be slower but it depends.
Main use case for database views is when there is a need to alter somehow what data will be published from the database in a stable and reliable way. Selecting just a subset of attributes for WFS, changing attribute names, computing new attributes on the fly, using joins etc. it pretty simple to do on the database side and it is also possible to optimize the SQL code and not to rely on the SQL queries which are automatically generated by Geoserver. For hiding some unnecessary of sensitive data the filters are not a real option. Even it is simple to make the client to send certain filters always it would be too easy for the users to fiddle with the code and rip off or modify the filters.
Filters are good for allowing users and applications to do either pre-defined or ad hoc queries and select a small subset of all the available data. The feature type may contain millions of features and they must be available for the users, but usually when user needs data a well filtered handful is enough. Views in the database are good for setting the upper limits for what is available from the database.
The SQL Views in Geoserver lie somewhere in between http://docs.geoserver.org/stable/en/user/data/database/sqlview.html as well as the prepared statements in WFS 2.0.0.