Self Tracking Entities versus timestamp column in database

In an optimistic concurrency scenario fo a web-app, I am considering to give each table the timestamp column (sqlserver), comparable to a guid. Linq to entities will then generate sql update queries like WHERE id = @p0 AND timestamp = @p1 when one decorates the timestamp column with a certain attribute in Entity Framework. When the number of updated records returned is 0 we have detected a concurrency exception.

In a lot of posts I am reading about Self Tracking Entities which may be an alternative or better solution. But I didn't see any advantage over the "simple" timestamp method described above. Apart from the scenario where the database is immutable and doesn't offer the timestamp column.

Which solution is better and why?

EDIT

Yury Tarabanko correctly states that STE is another concept. However zeeshanhirani's answer demonstrates that concurrency check is one main motive to track changes.

Lets rephrase the question: why would anybody use the STE concept for concurrency check where the 'timestamp column' method looks so much easier.

You are mixing two concepts here. STE is not about concurrency at all.

Self tracking entities just know how to do their change tracking regardles of how those changes were made. So you always know what is the current state of entities object graph. And you don't need to invoke additional change detecting.

What is STE.

EDIT:

"concurrency check is one main motive to track changes"

AFAIK STEs and POCOs share the same approach to concurrency check which simply results in additional where condition(s) in update statement sent to DB. Equivalent to this:

UPDATE [schema].[table] 
     SET [prop1] = value1, ... 
     WHERE [key] = key_value 
          AND [concurrency_prop_1] = concurrency_prop1_old_value 
          AND [concurrency_prop_2] = concurrency_prop2_old_value

So 'the main motive' to track changes is, well, to track changes in N-tier app.