In testing, the user on a db i\'ve used was a big jefe. In production, he only has Execute.
When I called,
Membership.DeleteUser(user)
After a little inspection I found the issue is this line in the aspnet_Users_DeleteUser stored procedure:
IF ((@TablesToDeleteFrom & 1) <> 0 AND
(EXISTS (SELECT name FROM sysobjects WHERE (name = N'vw_aspnet_MembershipUsers') AND (type = 'V'))))
There are 3 other similar lines for 3 other tables. The issue is that if the user executing the stored proc doesn't have access to vw_aspnet_MembershipUsers it won't turn up when selecting from sysobjects. I'm curious to know why that whole EXISTS statement is necessary.
Regardless, the following discussion, "Access to sysobjects to view user tables without having access to the user tables directly in SQL Server Security", has the answer. By granting "VIEW DEFINITION" on the views in question, the EXISTS statements will now succeed and you don't have to grant unneeded, unwanted, or excessive permissions to the user in your application's connection string.