User Story: is “so that” part optional sometimes?

User stories were first popularized in eXtreme Programming.  When they were first mentioned there was no format for them. It was not until later that a format was shared by an organization that used XP methods.  In fact there are multiple formats that have been popularized for user stories over time. But the main purpose for them has been the same.  Having a way to communicate the <who> benefits from <what> and <how> that benefit is recognized. 

Yes, the "so that" part might be obvious as you shared with your example but it might not be obvious to everyone.  For example in your example, I can think of many "so that" scenarios such as 

... so that I can conform to my companies security mandates to change my password every 30 days

... so that I can prevent my ex-wife from seeing my email

... so that I can keep it in sync with my banking site password

... so that it can be managed by a password manager using random generated values

Not all of those are really valid reason to provide that functionality but from a user perspective they could all be valid.  So specifying the reason that the functionality is needed in the product isn't wasted effort. 

Personally, I am not a fan of user stories, especially those written in a specific format.  I prefer to have something that provides the information needed to understand why a feature is wanted/needed, who will benefit from it in which way, and some way of knowing that we have satisfied the needs.  It doesn't have to be a specific format but I do like to keep the technological implementation out of the statement unless it is absolutely necessary to the solution. 

And just for the record, there is no where in the Scrum Guide that user stories or a specific format is mentioned.  The Scrum Guide mentions Product Backlog Items that are understood by the team.  The only hint of content of the Product Backlog Item is found in this bullet from the list of duties the Scrum Master has to the Product Owner

Helping the Scrum Team understand the need for clear and concise Product Backlog items;

So talk to your teammates and agree on how to capture the need statement in a way that works for all of you and that is "clear and concise".

Daniel gives a pretty comprehensive outline, but I'll also throw a few other thoughts out there.

There are plenty of alternatives to the stereotypical user story format, such as job stories, problem stories, and improvement stories. Although one of more of these formats could be helpful to the team to help focus on the problem at hand and the stakeholders impacted by it, I would advise against being too caught up in the format and focusing on clearly and concisely describing the work, preferably in a way that the Product Owner and stakeholders can understand to help them order it and make informed decisions about what adds value without needing to bring in the Developers to explain a technical component.

You may find that these different formats have their place. Or maybe just using simple natural language is better. In the end, it doesn't matter. Scrum definitely doesn't mandate the format for Product Backlog Items as long as the team can work with them.

In addition to what has been stated, the user story should be a promise to have a future conversation. This comes from Ron Jeffries, who proposed the 3 C's: The Card, Conversation, and Confirmation. 

We all know how to write a user story: 

As a <type of user> I want <some goal> So that <some reason>

A user story is not necessarily written at all; it is a placeholder for a conversation about a potential requirement. The format you describe is just a convention for a placeholder.

The "so that" part is very usefull, but sometimes can be redundant.

If the "so that" part is redundant, perhaps the value to be derived is redundant...at least from that user's perspective.

For example, as a user I don't really want to change my password at all, nor have anything to do with passwords. I know who I am and I derive no value from validating myself. I do want to engage in a useful transaction of some kind to achieve an outcome. The driver for password management could derive from some other source, or from a constraint, and a user story may not necessarily be the best vehicle for describing this.

In case of password change, there can be multiple different outcomes, which user could desire, for example, to continue the product usage after a forgotten password or make sure that someone else can't act like him or keep his personal information protected. 

So I think, there is always a reason to implement any feature, and the "so that" part is describing it, otherwise it would be waste of time and money to do. 

One technique is to exclude the bit of the user story that you refer to as "<some goal>".

e.g. As an e-mail user I want to [TBD] so that I can log in easily when I use a new device 

It might be that the e-mail user just wants to be able to change from a default, randomly generated password to something they find more memorable. So the original idea might be the best.

Or perhaps a better solution is available, like using single-sign-on from Google, Facebook, LinkedIn, etc.

By omitting the exact solution, it creates space for a more open conversation, and creative or less wasteful ideas to emerge.

Perhaps during this conversation, people ask "why does the e-mail user want to use a new device?" and more might come to light.

Let's imagine the mobile experience doesn't allow attachments to be added to emails, and there's evidence that this kind of user is therefore avoiding sending emails on a mobile, and instead often logging onto someone else's computer in order to send the message with an attachment. The user may feel the greatest frustration when they have to find and type their difficult to remember password, so this might determine the kind of change they request, but it might not be the best way of achieving what they want (or need).

During the conversation, and as more is learned, the story might be rewritten several times. It's possible that the reason might eventually end up as the goal, and the story might not describe a specific solution, but instead provide clarity on the opportunity or problem being presented to the Scrum Team.

It might go through these iterations:

• As an e-mail user, I want to [TBD] so that I can send pictures from my phone.
  
  
  
  At this point, a simple way to attach files (at least images) might be considered the best option.
  
   
• As an estate agent, I want to [TBD] so that I can send the pictures I take of an apartment to my teammates in the office.
  
  
  
  By now, the Scrum Team are likely to have more empathy with the user, and can perhaps understand that this is a business-critical flow to someone who works as an estate agent.
  
   
• As an estate agent, I want to be able to quickly take and send pictures of an apartment to my teammates in the office, so that the average visit to a client can be reduced by 5 minutes.
  
  
  
  Ultimately the Scrum Team may find themselves with several hypotheses which can be validated, along with new needs that weren't really being discussed in the beginning (such as the entire flow of taking and sending pictures having to be quick).

The result might be instead of building an option to change the password, which might not be important to anyone, the Scrum Team can quickly validate the hypothesis that this feature is worth building, by first talking to estate agents and examining their needs.

Also, rather than building a conventional attachment option, the Scrum Team might enable the user to take photos and directly attach them to the message, which would almost certainly save time for the estate agent.

And to validate their success overall, the Scrum Team may interview estate agents after release, to determine whether it really has reduced the length of the average visit by 5 minutes.

Thank you very much to all!