I think it's up to you, and it depends what you are using the UAT environment for?
If you are simply testing any changes or bespoke work, then maybe you aren't worried about how the work performs underneath.
However, if you want the testing to be representative of a production environment, then I would suggest making them as similar as possible. This way you have a chance of spotting issues before they become problems.
In my current setup, we have a test environment that mimics our live system. We also have a dev system, which obviously matches the live system in terms of the data, but the configuration of the vm is slightly different, as I'm personally not that bothered about performance here (or any developers 😛). This is what UAT is for.
Finding performance issues in UAT is finding it too late. It costs too much in rework or, worse yet, some bloody schedule dictates that the code will still be released to production even with the performance problems present.