This can happen for different reasons.
One case, is backing up a database from one instance of SQL server and restoring it on another instance. When you do that, the corresponding login is not transferred to the new instance because it exists outside the database’s scope. In this case you need to either create the login and map it to the database user or make use of the special stored procedure sp_change_users_login in order to create the database user-login association.
Another case would be deleting a SQL Server login (this is not a recommended action). This would leave the mapped database user orphaned.
You need to handle orphaned users. By just leaving them there you are actually maintaining a security risk because if a login is maliciously mapped to an orphaned database user, the login will inherit the orphaned user’s permissions on the database.
There is however a case where you can have database users not mapped to SQL Server logins and this could be just fine. This case is when you make use of a Contained Database. Contained Databases are isolated from the instance and you can log into them by just using their users. This is the only case where you must not consider a database user as orphaned.
There is a SQL Server security tool developed by SQLArtBits and which is called DBA Security Advisor which scans your SQL Server instances for vulnerabilities and provides recommendations and remediation scripts/methods. One of those security checks, is checking for orphaned users in all the databases of all instances to be assessed.
Recommended eBooks on SQL Server: