Migrating to Architectury would make the mod development much easier as it would completely replace gameadapter, which is the Forge/Fabric compatibility tool I developed myself, powered by mixins. It would also most likely make the mod depend on the Architectury API, which I don't know if this is something I want.

As the user, would that mean having to have two .jar files for the mod to work? If that's the case, it would turn away most people. If it can be integrated into one .jar tho, I'd say go for it

It will depend if I make use of the Architectury API or not. If I do, the user will also have to download the Architectury API mod because I don't think I'm allowed to bundle it myself in my own JAR.
As it stands it might be possible not to make use of the Architectury API for IBE Editor while still using their platform. I will look deeper into it later.

Created a new branch 1.16-architectury. It seems to be quite stable already. Haven't tried running the mod on an obfuscated env yet, but it compiles and runs on the dev environment (on Forge and Fabric).
I didn't make use of the Architectury API, which means no additional dependency for the end user.
The mod files are quite smaller than before (~100KB difference) because I got rid of the whole gameadapter layer. I've also "unmodularized" the mod for more clarity (DataBindings, GUAPI, GUAPI: Vanilla Theme and IBE Editor are all in the same module again). Makes the whole Gradle setup much cleaner, and modularization isn't something that I absolutely require for now.