Purpose of SQL Server Application Roles
Application roles do not eliminate the need to supply initial connection credentials. One must first successfully authenticate to the server/database using a login (SQL or Windows account/group), or contained database user) before an application role can be activated. 

Application roles mostly differ from regular database roles in that they:


have no members
are enabled using sp_setapprole with the app role password after successful authentication
are unset using sp_unsetapprole with the cookie returned by sp_setapprole (required for connection pooling)


There is no value in using an application role when a service account (with the permissions needed by the application) is used for application database access. 

A use case for application roles is when users connect to SQL Server from the application using their own security credentials (e.g. Windows authentication via Windows group membership) but do not have the permissions the application requires. Activating an application role in this scenario allows auditing of individual user activity (e.g. using ORIGINAL_LOGIN()) without granting permissions beyond CONNECT, although users could be granted permissions for needs outside the application, such as those needed for a reporting tool. This would allow read-only access for reporting while limiting writes via the application.