Here is a quick, partial answer for enwiki:

There is some truth to the hypothesis that category pages are more popular among logged-in users than article pages, in that the percentage of logged-in views is several times higher for the former. On the other hand, the vast majority of views to category pages still comes from anons.

Concretely, category pages have about 3% logged-in views compared to 0.8% for mainspace pages, but on the other hand that's still way lower than say for user talk pages (28% logged-in views). I generated the percentages for all namespaces on enwiki below while I was at it. See https://en.wikipedia.org/wiki/Wikipedia:Namespace for the numerical namespace IDs (category pages have ID 14).

Another thing to keep in mind is that category pages still receive vastly less pageviews than articles (less than 1/100th, in the data below).

There are various directions one could explore from here:

1. For large categories that are paginated, it's possible to determine how often the subsequent pages are accessed, as a check how much users are interested in the full content of such a large category, as opposed to just randomly clicking the category links at the bottom of articles. (E.g. the "next page" link on https://en.wikipedia.org/wiki/Category:2018_singles currently leads to https://en.wikipedia.org/w/index.php?title=Category:2018_singles&pagefrom=Disillusioned#mw-pages ).
2. It is possible in principle to exclude maintenance categories, as you suggested in the task, but that would require much more work than the quick query here.
3. Another way to answer the question from the task whether users use categories to find Wikipedia articles is to look at the number of article pageviews with a category page as referrer.

As mentioned earlier, I unfortunately don't have a lot extra bandwidth right now and thus won't be to tackle much of these anytime soon, although I might be able to run a query for 3. later this month, after completing a similar request for portals.

(Data for November 24-30, 2018, known bots excluded. NULL values comes from pageviews that didn't record the namespace, which IIRC encompasses the mobile apps. Otherwise the above data doesn't distinguish between mobile and desktop.)

Data via

SELECT namespace_id, -- cf. https://en.wikipedia.org/wiki/Wikipedia:Namespace 
ROUND( 100 * SUM(IF(x_analytics_map['loggedIn'] IS NOT NULL,1,0)) / SUM(1), 2) AS loggedin_percentage,
SUM(1) AS all_views
FROM wmf.webrequest
WHERE year = 2018 AND month = 11 AND day >= 24
  AND is_pageview
  AND pageview_info['project'] = 'en.wikipedia'
  AND agent_type = 'user'
GROUP BY namespace_id
ORDER BY namespace_id LIMIT 10000;

Thanks! This is great. I'm happy.

Noting for whomever may come across this: I suspect the above findings differ to some degree from present day. Since late 2020, the pageviews pipeline more reliably filters out bot traffic (ref). These bots crawl the wikis clicking on every link, so it seems highly probable the all_views figure above was partly automated traffic.

I tried running it myself on stat1007 with the following, and other variations of this query, and it always errored out with FAILED: Execution Error, return code -101 from org.apache.hadoop.hive.ql.exec.mr.MapRedTask. Java heap space. I tried giving it more RAM, etc., but no luck yet.

SELECT ROUND( 100 * SUM(IF(x_analytics_map['loggedIn'] IS NOT NULL,1,0)) / SUM(1), 2) AS loggedin_percentage,
  SUM(1) AS all_views
FROM wmf.webrequest
WHERE year = 2023 AND month = 6 AND day >= 15
  AND is_pageview
  AND pageview_info['project'] = 'en.wikipedia'
  AND agent_type = 'user'
  AND namespace_id = 14
LIMIT 10000;