PIC32 vs dsPIC vs ARM vs AVR, does the architecture matter when we are programming in C-language anyways?
This is quite an opinionated topic. I can speak for myself (AVR, ARM, MSP430).

Difference 1 (most significant) is in the peripherals. Each of the MCU has similar UART, SPI, timers etc. - just register names and bits are different. Most of the time it was the main issue I had to deal with when moving code between chips. Solution: write your drivers with a common API, so your application can be portable.

Difference 2 is the memory architecture. If you want to place constants in flash on an AVR you have to use special attributes and special functions to read them. In the ARM world you just dereference a pointer because there is a single address space (I don't know how small PICs handle it, but would assume that they are closer to AVR).

Difference 3 is interrupt declaration and handling. avr-gcc has the ISR() macro. ARM has just a function name (like someUART_Handler() - if you use CMSIS headers and startup code). ARM interrupt vectors can be placed anywhere (including RAM) and modified at runtime (very handy if you have for example two different UART protocols that can be switched). AVR has only the option to use vectors either in "main flash" or the "bootloader section" (so if you want to handle interrupts differently you have to use an if statement).

Difference 4 - sleep modes and power control. If you have the need for lowest power consumption, then you have to levarege all features of the MCU. This can differ a lot between MCU - some have more coarse power saving modes, some can enable/disable individual peripherals. Some MCUs have adjustable regulators so you can run them with lower voltage at slower speed etc. I don't see an easy way to achieve the same efficiency on an MCU (let's say) with 3 global power modes and another with 7 power modes and individual peripheral clock control.

The single most important thing when caring about portability is to clearly split your code to hardware-dependent (drivers) and hardware-independent (application) parts. You can develop and test the latter on a regular PC with a mock driver (eg. console instead of an UART). This saved me many times as 90% of the application code was complete before the prototype hardware came out of the reflow oven :)

In my opinion the good thing about ARM is the "monoculture" - availability of many compilers (gcc, Keil, IAR... to name a few), many free and oficially supported IDEs (at least for NXP, STM32, Silicon Labs, Nordic) , many debug tools (SEGGER - especially the Ozone, ULINK, OpenOCD...) and many chip vendors (I won't even start naming them). The PIC32 is mostly limited to Microchip (but it only matters if you don't like their tools.

When it comes to C code. It is 99% the same, an if statement is the same, a loop works in the same way. However you should care about the native word size. For example a for loop on an AVR is fastest if you use uint8_t for the counter, while on ARM uint32_t is the fastest type (or int32_t). ARM would have to check for 8-bit overflow every time if you used a smaller type.

Selecting an MCU and/or vendor in general is mostly about politics and logistics (unless you have very clear engineering constraints, for example: high temperature - use MSP430 or Vorago). Even if the application can run on anything and only 5% of the code (drivers) has to be developed and supported over product lifetime - it is still an extra cost for the company. All places I have worked in had a favorite vendor and MCU line (like "pick any Kinetis you want unless there is a very good reason to chose something different"). It also helps if you have other people to ask for help, so as a manager I would avoid having 5-person development department where everyone used a totally different chip.