Performance is a complex topic. I think, given the choice, people will usually prefer faster response times over slower times. There are many contributing factors to response times, especially with the move to cloud-based systems/services (network latency being an obvious factor to consider).
The dilemma with enterprise software, such as ERP systems, is that they are usually extremely expensive to implement and maintain. These systems are sometimes integrated with other third-party software from different vendors, or part of a larger landscape of inter-connected systems, with teams of people employed around the clock to make sure that service level agreements are not violated by a system that suddenly goes offline without prior agreement/notice. In that sense, businesses take performance very seriously.
Picking an ERP system is one of the biggest software investments your company will make. Your deciding factor is not going to be the difference between 1s and 3s response times. It will be price, features, stability, support, maintenance, and if it is the best fit for your industry/business. Depending on the system, you may even have to change your internal business processes to be more in line with the way the software "expects" things to happen.
Large ERP implementations can take more than a year, with many consultants on-site to do configuration and training. It costs a lot of money, but in the end, it is the backbone of your day-to-day operations, finance and human resource functions. Is it worth the occasional excess 2s in response time? From a business perspective, yes. Would they prefer a faster response time? Sure. Will they pay for a faster response time for user-facing actions? It depends, but probably not if it means switching ERP systems. And they won't switch for a 2s improvement in UI response time. At best, they may look into upgrading the server infrastructure (if they have that option).
Performance (or web-application performance specifically) can actually be split between:
- the time before you receive a response from the server after making a request (sending the request over the network, performing "back-end" processing (checking security permissions, fetching data from different systems/databases, consolidating the results etc), sending it back to the browser)
I have worked on large scale deployments of enterprise systems, and "acceptable performance" really depended on the environment. For the SAP Basis consultant it meant a response time of 2.5 seconds under normal conditions, even though this could spike up to a minute or more under heavy load. Response time here is basically asking the system for a status update, and receiving a response within that time (not to be confused with pinging a system). For the IT manager, performance was defined by the service level agreement, and could mean that 90% of the requests made within an hour period should each respond within 2 seconds (this means back-end processing, not browser rendering time). This was measured within the same data-center, and did not factor in latency due to geographical location.
My experience is limited to systems used internally by businesses, which seems to be what you were asking about. There are companies that take front-end performance (browser-side) very seriously, but they are mainly targeting the public (individuals), where perceived performance is a much larger deciding factor when choosing to use the service or not.
There is existing research on how long users are willing to wait for a response from the system, before thinking that something went wrong. I believe this was in the 10 second range, but I will have to look up the source. The research was done in the 80's, with users of text terminals if I remember correctly, but I will have to double-check. You can also refer to Jacob Nielsen's response time limits for a general guideline on application response times.