I've been burned too many times in the past with issues resulting from upgrades that I am probably wayyyyy to conservative when asking people to test. Releases are much better now and release management is cleaner, but old habits die hard :-)
The main things I look for when asking customers to go through a UAT on an in-place upgrade are unexpected side effects (unexpected to them) that have come through as part of a new release. If people are going through a point release, it's fairly easy to give them a list of what has changed since the release they were on and specifically look at those areas. I also recommend like for like upgrades and leave new fancy features to be put in once the upgrade has bedded in.
Sometimes bugs are fixed which change some functionality which people got used to or even relied on and these are not always easy to spot without testing.
I also look for areas where the LD developers put things back 'as they should be' when running an upgrade/MDM. This can trip people up when they have been legitimately changed. There are far less of these than there used to be, but you do still need to be careful and keep lists and test.
If a customer is moving from an elderly release (say 7.4) to a recent one, then they will see a lot of differences and people need to work through that beforehand and not on the day of going live! Our customers are likely to have a UAT test script so it's fairly easy to pick a few willing volunteers and run through that, plus introduce test for any new areas of the product that need exercising.
But if this is not an inplace upgrade, then a whole new vista of opportunities for small irritations can creep in if the new environment isn't set up the way the old environment way. How may people keep their as-built documentation up to date? So test reports to make sure UNCs work and shares with privileges, test knowledge base to make sure Lucene has been set up/works, integrated login, links to images for business object reports and so on.
I'd certainly make sure you can go through all the actions as a non-administrator that are used on a daily basis. Its quick and easy to do and sometime people find actions they didn't even know they had!
I'm reminded of y2K (yes I am that old and cranky). Across the board the general public wondered what all the fuss was about as nothing really went wrong. That's because there was a lot of testing done to make sure.
One interesting and quite common view with large corporates is they sometimes want to be be 1 release behind the latest so that any unexpected side effects or patches can be well understood because lots of other people have already used that version previously. With the current more rapid release time that LD have, that is quite easy to do. It's a bit conservative, but understandable when IS resources are limited.