No, no, performance should be part of the requirements.

Not in the sense that every project needs awesome performance. But in the sense that requirements should not what performance goals are required.

So you should note down target throughput and latency for different scenarios in your requirements.

That can be as simple as saying that any user interaction should give feedback within one second. (Be that either doing what the user requested within that one second, or giving some indication that the program is working on it.)

Yeah with that I agree, part of the requirements can definitely be what performance is required.

The way that GP comment was written though made it sound like good performance should be part of the requirements for all software, which is what I disagree with.

Why would a user care about how fast it was to build the software?

That depends on the user. As Joel Spolsky famously said, there are different spheres of software. Things like Word or Windows, which are general purpose and go out to millions at once, are one kind.

On the other hand, lots of software is custom-built for a specific end-user. E.g. an organization's internal tooling. There, you can often sacrifice a lot of things for it to be done faster, depending on the use case. In that case, I consider the user to be the "organization" or specific people/teams within that organization.