I'm glossing over quite a bit here, of course, but it's a decent semi-technical summary that would be suitable for communicating to others who are not familiar with Active Directory itself, but generally familiar with computers and the issues associated with authentication and authorization.
Active Directory is, at its heart, a database management system. This database can be replicated amongst an arbitrary number of server computers (called Domain Controllers) in a multi-master manner (meaning that changes can be made to each independent copy, and eventually they'll be replicated to all the other copies).
The Active Directory database in an enterprise can be broken up into units of replication called "Domains". The system of replication between server computers can be configured in a very flexible manner to permit replication even in the face of failures of connectivity between domain controller computers, and to replicate efficiently between locations that might be connected with low-bandwidth WAN connectivity.
Windows uses the Active Directory as a repository for configuration information. Chief amongst these uses is the storage of user logon credentials (usernames / password hashes) such that computers can be configured to refer to this database to provide a centralized single sign-on capability for large numbers of machines (called "members" of the "Domain").
Permissions to access resources hosted by servers that are members of an Active Directory domain can be controlled through explicit naming of user accounts from the Active Directory domain in permissions called Access Control Lists (ACLs), or by creating logical groupings of user accounts into Security Groups. The information about the names and membership of these security groups are stored in the Active Directory.
The ability to modify records stored in the Active Directory database is controlled through security permissions that, themselves, refer to the Active Directory database. In this way, enterprises can provide "Delegation of Control" functionality to allow certain authorized users (or members of security groups) to perform administrative functions on the Active Directory of a limited and defined scope. This would allow, for example, a helpdesk employee to change the password of another user, but not to place his own account into security groups that might grant him permission to access sensitive resources.
Versions of the Windows operating system also can perform installations of software, make modifications to the user's environment (desktop, Start menu, behaviour of application programs, etc) by using the Group Policy. The back-end storage of the data that drives this Group Policy system is stored in Active Directory, and thus is given replication and security functionality.
Finally, other software applications, both from Microsoft and from third-parties, store additional configuration information in the Active Directory database. Microsoft Exchange Server, for example, makes heavy use of the Active Directory. Applications use Active Directory to gain the benefits of replication, security, and delegation of control described above.
Whew! Not too bad, I don't think, for a stream of consciousness!
Super short answer: AD is a database to store user logon and group information, and configuration information that drives group policy and other application software.
Best Answer
edit: Wrote this answer before I knew you were talking about Exchange, so it's more about AD in general.
Yes there are limits. Your first consideration might be that the attribute you want to use is not indexed. This is as easy as clicking a checkbox to change. Indexing an attribute makes queries involving that attribute faster, at the cost of database and replication size.
Secondly, your custom attribute may not be replicated to Global Catalogs. This may be an issue if you have many domains and you might need to access this information from another domain. This is also easy to fix, but again, be mindful that you're adding replication load.
There are a ton of attributes already in the AD schema that are not being used. Perhaps you can repurpose some of them. For instance, the Likewise/Powerbroker and Centrify clients that allow Linux computers to join AD domains... no AD schema extensions are required because those clients use preexisting attributes in AD to store Unix-specific information.
Yes attributes have a set size limit, and that limit is different for every attribute. Not just size limit, but they can be different types of data as well. A multi-valued string, for instance. Each attribute can also have a specific allowed range, security descriptor, etc. These constraints are fixed as part of the schema. Here is a reference of Active Directory attributes... the info is a little old but the idea is the same. You have linked attributes, ANR (ambiguous name resolution) attributes, etc., that all behave a little differently and have different purposes.
As a last piece of advice - consider any changes you make to your AD schema permanent and irreversible. So do it only after a lot of forethought and planning.