SUMMARY
4th paragraph the meaning of "If the source that applies the timestamp is not available" - it's not clear what "source" refers to.
5th paragraph requirements appear to contradict the requirements in paragraph 3 and 4.

1st para:
"Once a value has been assigned a source timestamp, the source timestamp for that value instance never changes. In this context, “value instance” refers to the value received, independent of its actual value.".

3rd para:
"the timestamp needs to be set always by the same physical clock."
(suggestion: remove the word "physical")

4th para:
"If the OPC UA Server receives the Variable value from another OPC UA Server, then the OPC UA Server shall always pass the source timestamp without changes. If the source that applies the timestamp is not available, the source timestamp is set to null. For example, if a value could not be read because of some error during processing like invalid arguments passed in the request then the sourceTimestamp shall be null."

Did this mean to say: "if the source timestamp is not present in the received value, the source timestamp is set to NULL"?

If "source" refers to the underlying data source, then the statement ("the source timestamp is set to null") appears to contradict paragraph 1, because it is changing the contents of an existing value instance and requires the Server to assign a NULL timestamp to it, which also will now contain an error status. Per the statement in para 1, nothing was received, so the source timestamp should not change, even if the status is changed. The Server timestamp could be used for this purpose.
Further, the local Server is not the underlying source and should not generate the source timestamp - that should only be done by the actual source using its clock (per para 3)

5th para:
"In the case of a bad or uncertain status sourceTimestamp is used to reflect the time that the source recognized the non-good status or the time the Server last tried to recover from the bad or uncertain status"

These are different use cases.
If the source encounters an error collecting data, then it makes sense for it to assign the source timestamp when the bad quality was detected, and again when it recovers and has a value.
If the Server detects an error getting data from the source, then when it initially detects the error it sets the timestamp to NULL (para 4). When recovery is attempted para 5 requires it to set it to the current local time. I assume it only does this if recovery fails, because if it succeeds then it receives a VQTT from the source and will use that for the source timestamp.

1) a non-good status is what the 4th para appears to address (the source is unavailable or returns an error). The requirement seem contradictory:
     a) 4th para requires the Server to set it to NULL
     b) 5th para requires the Server to set it to when it detects the error, or when it tried and failed to recover.
     c) Both of these contradict the 3rd para, because the Server and source use different clocks
             (would it make more sense to use the Server timestamp for errors?)

2) the local Server's clock may be unsynchronized with the Source's clock, or may have significant drift, so using that for the source timestamp when errors occur may create unresolvable discontinuities. This will be more noticeable when there are long delays between when values are sampled versus when they are delivered, and there is significant clock drift.

Separate issues:
1) Setting the Source timestamp to NULL will causes problems for Clients that are subscribed to the value and are using the Source timestamp for time-series data, or to organize and correlate events distributed among processes. When the status changes due to an error the Client is notified and will get the original value, a NULL timestamp and an error code. This causes problems with applications that have "happens before/happens after" semantics.

2) This appears to assume the data is collected from another server - it could be that multiple Clients are writing to the same Variable Node with different parameters - some with source timestamps and some without.

I will open a separate Mantis issue about these other issues as feature requests. I mention it here as an example.