PIC assembly code can be quite nice to look at given a little extra effort in things like formatting.
I have written a lot of long code in assembly. 5 or 6 code pages... which is roughly on the order of 100 pages if printed out. I'm not suggesting anyone do that, but I have learned a thing or two about managing assembly.
As far as the code format, one thing I have evolved it to double indent the bulk of the code. Single indent on lcall's/pagesel and bank changes. No indent on jumps/returns.
The code history .txt is the most important doc of the bunch. I document what I'm going to do with "o's", there, and check of the boxes as I complete them, changing them to "x's". Of course always backup often, and use revision numbers between iiterations.
When revising or adding new code, I copypaste all the pertinent parts of the code into a scratchpad window (or two). Do the revisions there. I can scroll through the main code to look at the original code which I am modifying.... so that I will never double fix a logic error. And I can scroll the main code and have my scratchpad window side by side with any other pertinent code. And then copy this back in at the end.
When trying something that makes more than a minor change, which might break the code and make it worse, I will use assembly directives to try the new code. With the change of a constant, I can remove parts of the original code and replace them with the experimental code, and back again.
indented labels are one of the most important tools. No matter where you put them, you can get them to show up in the MPAB warnings. So whatever part you are working on, you can find, quickly. The IDE has tool to jump to labels... but it will only show the labels in the one file... not across all of them. And anyhow, you may have hundreds of label in a large code. (It also has a bookmark tool, which IMO is very cumbersome, and split screen tool which sounds great, but in practice it doesn't seem to work the way it needs to in order to be useful.)
And never.... never use macros. At first, you will think they are the best thing ever. Then you will busily convert a ton of code into macros. Then when you find out they conceal location of errors, you will pull your hair out.
The coolest thing about assembly is you have complete control over the device. I suppose if you completely understand functions of your specific C compiler (for which you would need to understand assembly even beyond the ability to write it), you would at least know exactly what your C code is doing. But building it yourself, your code works exactly how you need it to for specific task.
Take example of woodworking. I can buy a fancy general purpose jig that will do what I need it to.... along with perhaps many other variations of this task which might be useful in the future. This is C. Or sometimes for a specific project I can build a simple jig that does what I need, better (going back to the microcontroller, we're talking in terms of speed, code space, memory, execution speed, and/or repeatability of execution timing). Chances of it being useful in the future are perhaps slim. But I can build it differently for different tasks. This is assembly. You learn how to build your own tools, if you want, starting with stones and files and a microscope. So starting out with a full shop of Veritas planes and commercial cabinet saw and router table et al is going to allow you to make more cabinets and chairs, faster and easier. Having access to stones and files, you will be able to make and modify tools for building cabinets. Eventually, you will have enough tools to build basic furniture, and some of them will be unique. And you will have a different understanding.
My woodworking and approach to coding is similar. If I want a nice cabinet, I will buy it. If I need just some of the functions of a cabinet, and it has to fit in a specific odd space, in my particular house, I might build it. If I were the last carpenter on earth, I could eventually build something remotely resembling and functioning like a nice, cookie-cutter commercial cabinet.