Before to even be a programming challenge, this kata is a total riddle as for directives.
Reading if X[i] > X[j] then X[i] = X[i] - X[j], one expects a left to right parsing, and only for immediate neighbour. But then one has to decrypt the example. Let's try with arrow in other direction:

X = [6, 9, 21]
X_1 = [6, 9, 12] # <- X_1[2] = X[2] - X[1] = 21 - 9
X_2 = [6, 9, 6]  # <- X_2[2] = X_1[2] - X_1[0] = 12 - 6
X_3 = [6, 3, 6]  # <- X_3[1] = X_2[1] - X_2[0] = 9 - 6
X_4 = [6, 3, 3]  # <- X_4[2] = X_3[2] - X_3[1] = 6 - 3
X_5 = [3, 3, 3]  # <- X_5[1] = X_4[0] - X_4[1] = 6 - 3

It seems we first substract 2 from 3, then 1 from 3, then 1 from 2, then 2 from 3, but lastly we substract 2 from 1. Not left to right, not immediate neighbours, so what? Deep right to left parsing? Greater from next greater? Greater from lower? Strictly none of those. Let's assume it's a deep right to left as far as possible then ending as possible. But what if [21, 9, 6]? Plus three poor test cases, can't help a lot.

I really like puzzles, and this one could be great as a puzzle if it was clearly stated. If it's not a puzzle, then some things should be clarified, as a lot of people already noticed in discussion. Personnaly, I feel that tagging it as puzzle and replacing misleading instructions with some more examples/tests, would been more interesting… Then one can try it only when in "puzzle solving" state of mind.

Thanks for the (re)discovery!!

What complexity is about: how does the time processing grow against data growth.

Think about how many times you have to parse data. If you parse it once, that's O(n). Twice should be O(2n) then, but we consider it as O(n) cause time processing still grows proportionally with data size. That's what we want to know. If you parse the whole data for each item, the processing time grows quadratically with data, that's O(n²). You can see n as number of items.

So from here, you can deduce we also can have O(1): you don't parse data; O(n³): you parse whole data for each item for each item; O(n!): you parse whole remaining data for each item, O(log(n)): you parse half remaining data on each iteration; etc.

You'll easily find documentations, graphs, tutorials, and so on (even hundreds pages book). Just look for it :)

(If needed, a real pro will complete, precise, or correct…)

Maybe problem is less "one-liner obsessive" than "one-liner admiring" people ;)