1) Setting up koji is a pain. Yes, there is a bunch of tools (ansible playbooks, ssl cert generation in koji-tools, etc.) which make it easier but they are not covered in the official docs.
2) hub code - it is a big file but there are no clear benefits of refactoring it today. Original reason was related to cpython's ability to quickly handle many files. It is not an issue anymore, on the other hand there are no clear benefits for splitting. In the case of CLI I see it more appropriate (file per command, etc.).
3) web UI - yes, this is a problem. While ago there was a short discussion in koji-devel about creating a new web ui. As UI is completely independent of the rest of the code, it is pretty ok to start separate project working on it which wouldn't be affected by the slower release cycle of koji itself. There are some pain points (except old tech) in current implementation (proper web plugins are probably the foremost example) and I would be pretty happy if someone will start to gather requirements. On my (and probably Mike's also) side there is not much remaining capacity to drive that. Saying that web UI is a second-class citizen is overstating but it is definitely not top priority. I understand that it is the first thing user see and it does a poor job in 2021/22. I'm open to facilitate starting this project (and we can make it an item at a koji community meeting once again).
4) token authentication - no problem - it would be pretty easy to add it. It is a simple extension of user/password auth adding some crypto to that. Nevertheless, I'm not sure if there is any real-world usage for that. For testing purposes user/pw is enough, for any real installation ssl certificates should be ok (koji-ssl-admin from koji-tools makes it pretty easy). Anyway, I'm open to adding it.
5) I've made 1) short and want to expand it here. Documentation IS confusing and it needs to get fixed. We've added a lot in the last year or two but we're still maintaing old "howto" structures. Nowadays it is simply incomprehensible. As a coincidence I've created
https://github.com/tkopecek/koji-docs-ng last week to start a new structure and rewrite some parts. I want to keep it outside of koji for a while and when we will be satisfied we can merge it to the main tree. Man pages generated from CLI should be another part to be fixed which leads me to the last UX item
6) CLI rewrite - Another discussion was about this and especially about picking state-of-the-art CLI library. As often happens we've ended without decision as nobody had enough time to explore current terrain. Part of this effort should be the ability to automatically create man pages which should also improve usability.
7) non-xmlrpc API - simply declined because of capacity. Maybe there could be a separate project translating REST to XMLRPC as a workaround for such usecases.
I would be happy for people getting on some of these tasks. I really try to be as low barrier for contributors as possible declining only things which are basically a) dangerous or b) potentially causing troubles in future.