Such as...?

A hypothetically perfect immutable system does not need to be testable, maintainable, or understandable. It becomes a black box.

Even in those perfect conditions right level of abstraction may cause the system to be build with less code and faster.

That being said I agree that it's always a trade off; I actually did many refactorings where I threw an abstraction level out instead of adding more of them, resulting in faster and easier to maintain code. It's definitely not good to invest in abstraction blindly.

In a perfect immutable system, I'm still going to want my code to be as DRY as possible, because I don't like typing the same thing over and over again.

In this perfect hypothetical world, you wouldn't eschew abstraction; you'd just know exactly what abstractions to use to perfectly model the problem you're solving. Those ideal abstractions would be different, since the problem is immutable.

Ask yourself this: in this perfect world, would you code with a magnetized needle and a steady hand? Why not?

Not sure how the magnetized needle analogy applies here. The point of the hypothetical is to avoid developing your own extra layers of code for future reuse. Avoiding those that others have developed for you already would not make sense.

As to the rest of your point, yes. Anything in service of pure development speed would be desirable. If you could abstract and reuse something faster than you could implement it in some other way (eg copy/paste), then it would make sense to do so.