AVR is vastly better to program than 8 bit PIC — either by hand or by compiler from C — but some people still insist on using those PICs for simple things.
The "PIC32" name was originally used for MIPS CPUs but more recently ARM ones and PIC32A is an extended dsPIC (16 bit).
There is also now PIC64 which is currently a couple of different RISC-V implementations, one based on quad core SiFive U54 from 2018 (same as PolarFire SoC FPGAS), and higher performance (and rad-tolerant in some versions) octa-core SiFive X280 with vector processing. Microchip have I think also indicated there will be future Arm-based 64 bit PICs.
The PIC and AVR are both more about peripherals (and low power, since they can sleep while peripherals do things).
The documentation on PIC or AVR assembly is extremely short, less than 200 pages. But the chips other peripherals (MVIO, 50mA push/pull current at upto 5V, OpAmps, differential ADCs, Event systems, and more) is where these chips get a resounding advantage.
Except now PIC32 CM has those very nice peripherals (comparable to AVR DD at least). It's very curious to me how it all works out: if Microchip will continue porting their nice hardware to ARM, or if they'll continue to develop new stuff for the 8bit market.
----------
Because the peripherals are hardware, I don't think it's really too valuable looking at the assembly language or other comp-sci details. The 8-bit assembly languages, be it PIC or AVR (or 8051) are all sufficient. Enough CPU to do things and glue the peripherals together.
The "PIC32" name was originally used for MIPS CPUs but more recently ARM ones and PIC32A is an extended dsPIC (16 bit).
There is also now PIC64 which is currently a couple of different RISC-V implementations, one based on quad core SiFive U54 from 2018 (same as PolarFire SoC FPGAS), and higher performance (and rad-tolerant in some versions) octa-core SiFive X280 with vector processing. Microchip have I think also indicated there will be future Arm-based 64 bit PICs.