Equally serious question: what is the use case for Access?
It's been installed on every corp workstation I've had and it's never been useful. In my experience either Excel can do it or you need a real programming language/database.
Access allowed maintained "relations" between tables, so you didn't need any code to have a master/detail relationship between tables, it just handled it all. This carried over to forms, queries, reports, etc. You could have a system with data entry, master/detail records, queries and reports built in a day, all without ever doing any SQL.
Through ODBC, you could connect to pretty much any database around. I think Office 2000 Professional was one of the best products Microsoft ever produced, it's all downhill since then.
I know of small companies and charities that would use Access as their homegrown CRM back in the 2000's. It worked really well, you just needed one guy who'd be willing to set it up and they'd be good to go with the basic forms for a couple of years usually.
It's definetely not great by todays standards when it comes to backups and what not, but it was really fantastic at the time.
Access had a very low barrier to entry and sanitized inputs. Excel doesn’t cater to minimally skilled people who want to hand off forms to someone else for data entry.
Why is this zip code a phone number? It’s not the users fault, your using the wrong tool.
Access was an app you had installed on your workstation but never opened because in the backend every late 90s early 2000s desktop app was using it as its data backend.
Between Excel (with no functional API to use for storage) and a "real database" (your users now need to ask IT to deploy SQLServer) was a use case of app just needs to store persistent data for a single user.
I remember there was at least one video game (some turn-based tactics game, don't recall the name) that had Access as a savegame format. It was very convenient to edit the save file.
Those business apps made "by that one person" that allowed few other to input data concurrently (back then no google sheets / shared Excel... which are horrible and have no user defined GUI) and then to make reports.
Also data manipulation when it didnt fit Excel (I know access has 2gb limit, but it was a lot).
Prototyping - occasionally when starting out on a big in-house development project, we'd task one or two guys to build a prototype in access to understand the challenges, functionality, data issues and get user feedback on what worked and what didn't. Invest 3-4 weeks of effort that saved us months of effort from the project overall and de-risked the project substantially. One time it back-fired a bit when the users liked the access proto-type more than the final system (pushed the envelope a bit too much and the performance was very poor), but typically got plenty of value out of it.
I used it to create a detailed opinion of cost with recursive summing, so that item costs were summed per section, section costs summed into summary costs, summary costs summed into project cost.
No other document designer that I'm aware of allows for runtime integration of variables into the layout/presentation.
Seen a lot of screw-up by someone taking a databse export (csv or whatever) into excel to work on it, sorting but only sorting one column leading to disaster.
It's been installed on every corp workstation I've had and it's never been useful. In my experience either Excel can do it or you need a real programming language/database.