I built this list, because sometimes I'm bored enough to write the same things again and again, so I have stable place to link.

1) PICs require awkward proprietary tools based on Windows, so you can't use it on Linux or Mac.

Nope, see points 2 and 3.

2) There are no free (as free beer) tools for PICs.

No, there are. XC compilers - for 8-, 16- and 32-bitters - are available for Windows, Mac and Linux. If you wish, you may also use their MPLABX IDE, available for all three platforms as well - at no cost.

Note those compilers are stripped down version of paid compilers. You have worse optimizations for compilers (IDE itself is unrestricted), but it is simplest way to start. On the other hand, the compilers are perfectly adequate for DIY use; from my experience the difference between full and free compiler in case of XC32, is something around 2-6% of code and 5% speed penalty for free version, though YMMV. I understand somebody may not want this, so here we go to point 3:

3) There are no free (as freedom) and open-source tools for PICs.

Again, no. You can go barebones and compile from command line on your raspberry pi zero with SDCC compiler for 8-bitters or vanilla MIPS GCC for PIC32. Both are open-sourced.

I used SDCC in my project #Micro progmeter where is also quick guide for setting up the compiler with MPLABX IDE, though you can omit the IDE part and use compiler only. For PIC16 and PIC18, there is also open-sourced programmer #Microchip PIC Arduino based programmer so you have fully free and open-source toolchain for 8-bitters. SDCC is used also in Pinguino project, which is Arduino derivative for PIC micros.

When it comes to PIC32, you can use compiler from MPIDE too, which is Arduino derivative for PIC32. I personally use free tools for PIC32 with retroBSD project (BSD Unix running on PIC32) which has also set-up guide in case you don't know how to build your own compiler. In the case you don't want to build your own, you have ready to go binaries here.

Also, check out this toolchain based on GCC 8 for PIC32.

4) PICs are 4x slower than AVR, because it has clock divided by 4.

Nope, because wrong terminology. When it comes to 8-bit PICs, they have not divided clock, but 4-clock core, so it needs 4 clock cycles to execute one instruction. 16- and 32-bitters are different story altogether and folks insisting on 4x slower PICs usually have no idea about it, which gives clue of their argument quality. So, while we agree that PIC needs 4 clocks for one instruction* and AVR only one**, the AVR usually ends up at 16 or 20MHz (=16 or 20MIPS), while PIC18 are going to 64MHz (=16MIPS), delivering approximately the same speed - definitely not 4x difference.

* and ** - only short instructions take 4 or 1 cycle respectively. For AVRs, you have a lot of two, three and even four cycle instructions. There are corner cases where one architecture has advantage over the another.

5) 8-bit PICs are nasty to program, with poor instruction set and banking and whatnot

8-bit PICs are barebones RISC architecture, which is human unfriendly by definition. If you are faint of heart, don't do it. With PIC18 and newer PIC16 devices, you are really occasionally forced to do any banking at all due to access bank (for direct variables) and FSRs (for buffers and arrays). I've done a few medium to larger (more than 5k lines of asm code) PIC18 projects and all of them NEVER touched bank select register except of single initial setting once after reset.

All this applies for programming in assembly language. Use compilers and you can forget it.

6) Microchip is closed source, hobbyist unfriendly, while other vendors are not

Welcome to the real world. Most of hardware vendors don't give a shit about open-source tools, though some of them are using it for their own advantage. In fact, hardware vendors don't give attention about YOU, hobbyist, unless you buy truckload of silicon every month. Atmel didn't give a flying fsck about AVR-GCC for years - read here. As well as Arduino was unnoticed for years, until they realized it is great way to promote them self and stick booth at every makerfaire. The debug protocols for AVRs are closed source, that's why you still don't have widely used and reliable open-source debug tools for AVR - and don't get me started about the Atmel Studio, Microsoft windows-only bloatware from Atmel. Situation is somehow better for ARM vendors (because ARM corporation has it's own requirements which has to be fulfilled by vendors), but point me out to the sources of ST-Link, please. Or LPC-Link. That's above the requirements, so no avail.

Microchip isn't generally better than this, though there are some efforts - it started with PicKit2, opensource (it started in 2004 or so, long before open-source was cool for MCU vendors) debug tool by Microchip. Unfortunately officially discontinued, but community around this is still vital, hardware is available and a lot of people use it. Another one is MPLAB Xpress loader.

But anyway, don't expect wonders from MCU vendors, they are producing hardware and expecting big money.