What are all consequences to consider when explicitly setting timestamp of a CQL statement INSERT INTO ... USING TIMESTAMP 123? Why not to use this just as another data column holding a time value instead of actual (unique) write time?
Scylla (and Cassandra) use the timestamp for conflict resolution: If two updates to the same data arrive, the one with the highest timestamp wins. If you write some data with timestamp 123, and a week later try to overwrite it or delete with timestamp 122, the overwrite will get ignored, because Scylla will consider it to be older than the existing data!
Another thing you notice is that the the timestamp is per "cell" (column in a row) - there isn't one timestamp for the entire row. For example, you may INSERT a row at timestamp 123 and later UPDATE just one column at timestamp 124 - and the result will be a row with multiple timestamps.
All of this is quite unrelated to the ability to have a column (one such column in a row) containing a value representing time. CQL even has a "TIMESTAMP" type which you can use for holding a time column - but it is completely unrelated to USING TIMESTAMP (and to add confusion, the TIMESTAMP column type uses milliseconds, while USING TIMESTAMP uses microseconds).
In general, if you use client-side timestamps (USING TIMESTAMP), it is wise to use the real monotonic clock on your client and not some made-up numbers like "123" - this will make it easier to later to continue to modify the database from other clients. But remember you usually don't need to use client-side timestamps at all - if USING TIMESTAMP the server receiving the write request will use its own clock as the timestamp (you should ensure that the clocks on all nodes are synchronized).