Is there any benefit to storing user information in AspNetUserClaims with Asp.Net Identity 2?

At the end of the day, your signed in user will be converted into a series of claims stored in the ClaimsIdentity representing your user in HttpContext.User.Identity. You can choose to store FirstName/LastName as columns in the user table which you then can explicitly read out and convert into the appropriate claims (if desired), or you can store them directly as claims in the AspnetUserClaims table (which is just stores them as two string columns) which by default will just automatically get added to your user's claims identity. Both methods are more or less equivalent though, so its up to personal preference.

BTW the only reason you would want these in the user's ClaimsIdentity at all, is if you wanted to save a db hit just to display the name, and always use the FirstName/LastName claims in the ClaimsIdentity. If you fetch the user, and use user.FirstName instead, there isn't much value in also generating the name claims.

In addition to @Hao Kung, when claims are going to be longer than allowed Cookie capacity of the browser, claims information could be trimmed.

According to Thinktecture Identity Server article, one of the famous alternative of default AspNet Identity, it said as below.

Once your application becomes complex, so are the number of claims to handle. By default, all the claims are stored as part of the session cookie and browsers like Safari impose a restriction on the size of the cookie. So one fine day, when you add few more claims to the application, you will start getting serialization errors. That's because only partial cookie will be sent back to the server and server does not know what to do with it. So the solution for this problem is to create the security token in "Reference" mode. What it means is to store the token on the server and just store a reference session id as the cookie. See the image below. The cookie size is just few bytes: