...as far as I know the PIC18 still only has 1 accumulator
Just to be clear, I thought we were talking about PIC18's now...
It is more of a efficiency and read ability thing.
say you need to store the value 0xA1.
On 8 bit PIC you only have 1 general purpose register W. So instead you need to first Allocate a piece of memory so you can access it across banks.
cblock 0x70
Reg1
endc
Then you need to
movlw 0xA1
movwf Reg1
AVR comes with 16 general purpose registers you can use so unless you need more then 16 self defined variables you can just use those ie.
ldi r16, 0xA1
So 5 lines becomes 1 line.
In your example movlw 0XA1 is identical to ldi r16, 0xA1 and loading more literals into accumulators for further processing is a little futile as you can have the compiler pre-process these literals to give you a result that doesn't need to be calculated at run time.
As a possible game leveller PIC's have a lot of instructions that allow you to operate on the memory directly, where as it appears that the AVR's require you to load them into one of the regs first. If you combine this with overlay memory you can create a volatile memory buffer that is accessible across all banks
With PIC it is possible to remove the cblock and replace it with a 1 liner which gives 3 lines to 1 line. The 16 registers will be more then enough for all but the most complex projects. You can achieve the same concept with PIC as the Common Ram is indeed 16 bytes on my PIC16F1829 which is 16 registers you just have to go through the process of defining them, and moving data to them which could be shortened with a macro I guess.
I don't remember the compiler directive but have a look for overlay in the asm manual as I mentioned above. You don't have to define each and every slot just create a block and index into it.
It really comes down to personal preference I just don't see why they could not give the 8 bit pics a load immediate opcode and 16 pre defined registers in that common ram saves typing which saves making mistakes.
The more I look into it and learn more it is very possible for me to create some convenience code in an include file to deal with a majority of these issues I have.
Macro's play a massive part of your assembly development environment. Unfortunately as time progresses and you invest more time and energy into this you run the risk of not wanting to dump your setup in favour of higher level languages
The pic16's where not designed as "C compiler friendly" and thus are more suited to asm whilst the AVR's with their registers and hardware stack manipulation commands are ideally suited for C compiler constructs.
As you start moving to more complex architectures you start seeing more and more features aimed squarely at supporting compilers. With this in mind the architecture designers start taking advantage of the fact that the assembly will be generated by algorithms in compilers and it becomes difficult to keep these "rules" in your head as you hand assemble.
For example a different set of assembly instructions sequences may seem to do the same thing but due to the pipelined nature of command processing one sequence may create a stall in the pipeline because the following instruction has to wait for the previous one to complete its operation before it can continue.
I guess the crux of what I am trying to get at here is that you are learning asm on an architecture that was "designed" for it. If you are going to move to an architecture that's been designed for programming with a more advanced tool then take advantage of it and use it (ie C/C++)