I remember building a COM object based system where the com objects represented entities which corresponded to tables in the database. To avoid having to change the interface of the com objects everytime we wanted a new data item we implemented a EAV model in the database table and exposed this through generic methods. In the end performance and the programming model were compromised.

At the end of the day what you are doing is replicating what the database engine is doing under the hood at a higher level. Databases are good at referring column names and tables and constructing queries based upon them. Its also not generally a problem to alter tables to reflect user requirements (although the application model cant be rigid as in above), or to have specific table constructs to handle user data etc.

One additional aspect I have not seen covered is reporting. Every tried to stick a third party reporting tool onto an EAV model? Not pretty. You end up having to build views to construct virtual tables based on the EAV tables and performance takes a further dive.

As has been pointed out where EAVs do work well is in auditing and event reporting. Auditing especially works well with a table, column, oldvalue, newvalue type of EAV, but this is a specific case. In general I would stay well clear