Is there any reason that metadata should not be a part of my database schema? By metadata I mean things such as:


the owner of an entity
permissions associated with an entity
the date and time of data entry
the surety of entered data
the format of a text attribute
descriptive names for attributes


This is all just data as far as I can tell. I might implement entity ownership by giving an Entity table a foreign key to a User table; I might store all text fields as two fields: content and format. And so on...

Is there any difference between data and metadata as far as practical database design is concerned? Why might I want to store my metadata somewhere other than my database?
Most DBMS already do store metadata in the database.  This data is general stored in what is broadly referred to as "system tables".  

The metadata that a DBMS will store already will be what it needs to operate the database.  Some of the types of metadata you've mentioned, e.g. ownership, permissions, and possibly even formats and descriptive names are already stored in your DBMS's system tables.  

Other types of metadata (e.g. date/time of data entry) are record oriented, as opposed to the table or column oriented metadata that you can find in your DBMS's system tables.  Record oriented metadata needs to be stored using a mechanism that you design and implement yourself.  Typically, this means storing the record oriented metadata with your records directly.  In some cases, you might find it helpful to normalize out some kinds of record oriented metadata into a common repository.  An event log that tracks events for multiple tables is an example of such a common repository.

How you handle your metadata depends on what you need it for.  As a matter of best practice, let the DBMS do what it is designed to do.  Don't track metadata manually if the DBMS is doing it automatically.  Only manually track the extra metadata.