Is more performant code most of the time also less readable?

I don’t think there is a simple relationship between performance and readability, but they aren’t completely independent. Many choices in programming can improve readability but also put a bound on achievable performance.

For example, suppose you choose a programming language that offers a lot of dynamic features at runtime. You might be able to express your ideas more easily using those features. On the other hand, you also need a runtime system to implement those features and that system may have a performance cost.

If you choose a programming language with a high level of abstraction, again you might be able to express your ideas more easily, but you might not be able to control the generated code to ensure that it fully exploits hardware features like parallelism and caching. In some cases, your compiler or interpreter might still do that anyway, depending on the semantics of the language and what the tools can safely infer about your program’s intended behaviour, but this is the classic “sufficiently smart compiler” argument.

An example not involving choice of programming language would be limiting your program to simple, well-understood data structures and algorithms. This makes your program more accessible to developers who are only familiar with the common tools. On the other hand, what if there is a more sophisticated alternative that is faster or requires less space, but the algorithm relies on building and navigating more complicated data structures? What if that alternative isn’t a standard technique that new developers can look up in a textbook, but rather something created after months of work by your own subject matter experts, who have since left the company? What if it is a standard technique, but one that is usually used to solve a different kind of problem, and it happens to be applicable in your current situation because some specific insight about your problem lets you reduce it to the standard one?

What about still using JavaScript, still having readable code and getting the execution time to 1-2s?

These things always depend on context.

With my UI hat on, a 1–2s delay can still be very noticeable to users. For a tool that runs on every save and where the developer is likely to check the results immediately — say, running a test suite, or building and then hot-reloading in a browser — that could still have an impact on each developer’s productivity. If each developer has several tools like that, and there are millions of developers, those little delays still add up to a significant overall drag on the industry.

On the other hand, for a background job that runs only under specific conditions that don’t happen very often, a few extra seconds is probably irrelevant.

But given your scenario: what if changing to the other language and the less readable code keeps other developers from extending the tool, writing plugins and stuff? So what if you have to give up all those contributions from other people?

Well, in this particular thought experiment, you could afford (in the productivity sense) to have a few thousand developers drop whatever they're doing and work full-time on developing your original tool instead for years and you’d still come out ahead. You can teach a lot of people a new programming language and explain a lot of correct but less readable code in thousands of years.

The real point here is that there is often a balance between making things easier for developers and making things better for users. Popular wisdom in our industry says that making things easier for developers is usually the right answer because developer time is expensive, but this is a conceit.

If there are few developers but many users, a little extra cost for developers may create a much bigger gain for users, taken over the groups as a whole. We’ve already been talking about a good example in this discussion.

This isn’t the only situation where developer costs aren’t necessarily the most important factor. What if the development environment is cheap but the runtime environment is expensive? If you have cloud infrastructure and usage-based pricing, maybe improved software performance would mean you could serve results twice as quickly or only need half as much storage. You can just throw more virtualised resources at an inefficient system in the cloud, but your infrastructure bill won’t thank you for it.

Related considerations arise if your software will run on a specialised platform like a supercomputer or a satellite or a tiny embedded medical device. Sometimes you have access to highly specialised but strictly limited resources, and you might not be the only one wanting to make the best use of them. Obviously each of these is a niche application, but there’s lots of software that isn’t web and mobile apps, and those developers also have to make trade-offs between readability and performance sometimes.