They do not serve the same function.
Putting a relative locktime in the nSequence value means "this transaction cannot be mined until its input is at least that old".
Putting a relative locktime with OP_CSV in the script means "Require that the transaction spending this sets an nSequence of at least this value".
The reason why they are split up is to make transaction validation independent of time. If the value passed to OP_CSV would be compared against the time directly, and it failed, there would be no way to distinguish whether the transaction is just outright invalid or it's due to a temporary locktime/nsequence constraint.
In other words: splitting them up allows up to see the spending transaction, verify it once, and know for certain that it's valid. We never need to evaluate it again, as this validity never changes; if it is valid once, it is valid always. The question of when it can be mined remains independent of this, and can easily be checked by just looking at the nSequence value and comparing it with the blockchain's time.
1Are you asking about why two ways of formatting, or why both in script and in nSequence? The "30d" is just notation to make the example easier to read; the encoding inside a script or nSequence is always the same. – Pieter Wuille – 2016-06-11T09:25:31.783
Just why to put the information in two places but you answered below. Thank you. – Gabriele Domenichini – 2016-06-11T18:54:16.073