From someone that is asked to support add hoc reports generated on an EAV it is a difficult exercise to convince end users why certain types of reports are fine and others aren't. Its a way too technical distinction.

Most non-technical are either happy with the concept of a linear performance degradation as per flat file scanning. Or expect a logarithmic performance degradation as per effective b-tree indexed relational database.

Having a EAV limits indexing possibilities.

SQL2005 pivot requires the column names to be defined in the query which makes it unsuitable for EAV. (any usefully implementation has dynamic Attribute set not determinable until query execution)

If you know the Attributes of the entity prior to query execution then persist them into the database schema as columns. Sure an index only sought and returned a record in 2005 is efficient. But it is not as trivial returning an additional extra couple of hundred bytes of an additional column on the same table.