So, if characters @, / and + are reserved, and should always be encoded (or I'm I missing something?) ...

The URI spec states:

"URI producing applications should percent-encode data octets that correspond to characters in the reserved set unless these characters are specifically allowed by the URI scheme to represent data in that component. If a reserved character is found in a URI component and no delimiting role is known for that character, then it must be interpreted as representing the data octet corresponding to that character's encoding in US-ASCII."

If we then examine (for example) the syntax rules for path we see:

 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" 

and '+' is in sub-delims.

So the URI spec is specifically stating that + should NOT be (automatically) encoded in a path. And indeed, it then goes on to say that the + means a + data character in that context.

So, if characters @, / and + are reserved, and should always be encoded (or I'm I missing something?) ...

The URI spec states:

"URI producing applications should percent-encode data octets that correspond to characters in the reserved set unless these characters are specifically allowed by the URI scheme to represent data in that component. If a reserved character is found in a URI component and no delimiting role is known for that character, then it must be interpreted as representing the data octet corresponding to that character's encoding in US-ASCII."

Firstly, it clearly does not say reserved characters "... should always be encoded"

For example, if we examine the syntax rules for path we see:

 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" 

and '+' is in sub-delims.

So + should NOT be (automatically) encoded in a path.