I've seen and used EAV in several cases and, like you said, it's all in the context of the data that is being stored.

In short, if the data points are known beforehand, tend to stay static and are well defined then simply use a relational model with proper normalization.

On the other hand, sometimes even the customer cannot know in advance all of the possible future data points they may need to track (that is why the NIH/CDC uses an EAV model for tracking diseases - you can't know all of the variables in advance). In this case, an EAV structure allows new datapoints to be added at-will without invalidating older data (since the older, related data will simply not have the newer attributes).

There is naturally a concern with those terrible End Users adding attributes to the EAV store willy-nilly... that's why you restrict the attribute definitions to an administrative screen with limited access.

I can't tell you how many databases I've run across with hundreds if not thousands of columns for a single entity which were mostly filled with NULLS and required expensive program rewrites every time a new data point (column) needed to be tracked. EAV fixes this and makes searching a snap. Reporting can be a bear, like others mentioned, because of the need to 'flatten' the data and yes, there is a performance hit as well, but when Scalability outweighs performance issues, then EAV/NVP may be the way to go.

Just like Indexes are a fantastic way of speeding up queries, adding 100 of them to a single table is probably a bad idea and makes things worse instead of better. Everything in moderation, use the right tool for the job at hand.