Good point! When I was new to the Zulip codebase I thought the same but after a while, my views changed. Its a very long model (and file) but very linear and organized, so it doesn't have that usual set of problems for which we have the common wisdom of not having long classes or methods.

Basically, for this you have to ask yourself why you want to split it and what would you split it to. If ultimately what we'll get is something like UserProfileA, UserProfileB, UserProfileC, then that's arguably worse than one long UserProfile.

Having worked in Django a lot I actually quite like big UserProfile models, they're significantly easier to manage at scale than several (often overlapping) smaller models. The migrations are less tedious, and it's easy to see "everything" for a given user in one place.