In reduce...spread complexity isn't x^2 at all. More accurate complexity will be arithmetic progression (the simplest case) + linear time = O(n*(n+1)/2) + O(n). Am I wrong?

It's possible yours is a better fit, yes. However, the first term in your approximation contains n^2 which will still dominate as you approach infinite, i.e. it is still quadratic time and can be classified as O(n^2).

Thanks for the detailed explanation.
I just published an ESLint rule package to detect this pattern.
https://github.com/cesarviana/eslint-plugin-no-reduce-spread-anti-pattern .

Great write-up, great stuff! Funny thing is that failed HackerRank puzzle brought me here. Some of the test cases were timing out and I had no idea why. Now I know :)

Pretty interesting research. In general, I was interested in the comparison of Object.assign and Spread operator. I've run your tests in various environments: node and browser(Chrome) and results significantly differ. In node.js results is the same as yours, but in the browser, the speed of Object.assign and Spread operator has differed with yours (they are nearly equal with the advantage of Spread operator)

That's interesting to look at but I wouldn't get too wrapped up in benchmarks between spread and assign unless you have a really good reason to. Constant time improvements between various implementations can change overnight, but the runtime characteristics of algorithms belonging to different computational complexity classes will remain the same.

Thanks, this was really interesting. I did not enjoy my algorithms class at the time, but in retrospect it was one of the most useful courses in my CS degree. I also find the reduce...spread pattern harder to read (although I guess once you see it everywhere it becomes easier).