It is because this way, the same e-mail address can be used by multiple Persons as well as the same Person can use multiple e-mail addresses, i.e., it makes the relationship between person and e-mail address many-to-many.
If the need was merely to enforce that the e-mail address should belong to a person, it would have been enough to make it a foreign key and the column BusinessEntityID not nullable.
Update:
There are 2 tables involved here, Person and EmailAddress.
Each record in Person is identified by a BusinessEntityID. To associate a record from Person with a record in another table T, it is enough to include a column in this table T that refers to BusinessEntityID. Now, if we needed to ensure that all records in T must be associated with some record in Person, then we would place a foreign key constraint on T.BusinessEntityID and make it not nullable. If on top of this, we wanted to ensure that each record in T must be associated with one and only one record in Person, then we could place a uniqueness constraint on the column T.BusinessEntityID.
When we make 2 columns, A and B part of the primary key of a table, we are telling the database that the values of these two columns together must be unique for all records in that table. It has no bearing on the values in each of those columns and any foreign key relationships.
To illustrate:
Person (BusinessEntityID, Name) and PK is BusinessEntityID
---------------
1 | John
---------------
2 | Jane
---------------
3 | Sales Team
EmailAddress (BusinessEntityID, EmailAddressID, EmailAddress) and PK is [Business EntityID, EmailAddressID] where EmailAddress is auto-incremented
--------------
1 | 1 | john@example.com
------------------------
1 | 2 | john@contoso.com
------------------------
2 | 3 | jane@example.com
------------------------
2 | 4 | jane@contoso.com
------------------------
1 | 5 | sales@example.com
------------------------
2 | 6 | sales@example.com
------------------------
3 | 7 | sales@example.com
Data similar to the above is possible to put in the tables in your example. Now what is happening here?
There are 3 entities, John, Jane and Sales Team.
John has 2 personal e-mail addresses. Jane also has 2 personal e-mail addresses. In addition, the e-mail address sales@example.com belongs to the Sales Team but also to John and Jane.
This is a many-to-many relationship.
Additonally, if the composite key in EmailAddress is clustered, the keys are stored in the order in which they appear. Read this for more information.