Arguments I use for people that over use meta-data Models. (Mostly by over zealous C++, C#, Java Developers, UI developers, and beginning data modelers)
You May Not Know Your Business
The purpose of Data Modeling, in short, is to accurately define your business and relationships between business concepts in great detail. Meta Modeling your whole business sends a red flag which states that you may not know your business or that your business is not well defined to begin with. Business is all about knowing the needs of your customers. So go back and do your ‘Use Case Modeling’ before building yourself a crystal castle. Go and actually get to know your customer’s needs. Otherwise, you build a system for a non-existing customer or worse; you build to your own ego.
Meta Models Are Expensive
Meta Models are expensive over the life of an application/service/tool. The more complex data it must contain, the more it costs to maintain. Beware, Just because you meta modeled the system doesn’t mean that you made your system easy to extend its features over the life of the application. Some times it makes it prohibitedly expensive/risky to modify, especially when the original developers move on to other projects or companies. KISS the project (Keep It Simple Stupid). Where possible, make the project easy enough to maintain by contractors off the street.
Don’t get me wrong: Meta data models are great for well defined uses. But question its existence and use it sparingly. If in doubt, define it out. Basically Model the business out first. Then only collapse specific areas into metal Models where it becomes PAINFULLY obvious that you need it for the Business/Process. There are many types of meta models. You may find that you only need a simple meta model for one very specific thing rather then having to create a unification theory to solve the worlds problems (Over Engineering).
SQL Server is already a Meta data engine
SQL Server or any other database product is already a Meta data engine. So build around its strengths and strengthen specific areas where it has been imperially determined to be insufficient. This means that you start building real useable and scalable prototypes to prove your designs and/or bring to the fore the Database System's Design Flaws. DON’T ASSUME OR GUESS. You don’t want to explain to your boss why you decided to build a database system on top of a database system instead of solving his business needs. :)