Webapp & MySQL: Row Level Security
How does creating mysql user per webapp user make the webapp less secure?

All you have to do is run SHOW GRANTS; within the app's DB Connections and all grants for the connected user is exposed. That may include seeing host IPs, subnets. Grants for specific tables, views and columns also become visible.

Does the disk I/O increase considerably?

It would definitely do so. Although grants and views are stored in the information_schema database (in RAM), each view would be stringently checked to make sure the underlying tables exist for using the view definition. That would requiring accessing the .frm for every table involved. Any grants on tables or columns are also checked against the underlying .frm files.

Is there a better way to implement row-level-security in MySQL?

This may be a little crazy, but you could probably use triggers

Example
delimiter $$
CREATE TRIGGER check_row_priv BEFORE UPDATE ON t1
FOR EACH ROW
BEGIN
 IF (USER()='user1@localhost') &amp;&amp; (OLD.is_editable=0)
 THEN
    -- Make Trigger Fail Here
 END IF;
END; $$
delimiter ;

I wrote another post that show how to abort stored procedures and triggers. Other answers in the question may give you insght into aborting triggers or, at least, makikng data immutable.
What are the pros/cons of implementing row-level-security by the above method?

IMHO In a nutshell, it would be the complexity of management.