I always think portability should be considered. But everything is always a balance between cost/performance/readability/... so there is always decisions that needs to be made.

I try to go for a mix.

I try to use uint8_t or other variants of data types that have a fixed size, or a minimum size, or are considered "fast".

I try to figure out where I can split code into two halves - one half that is target-specific and one that is general.

For code that doesn't need to share data storage with any other program, I may use raw data accesses. If non-volatile storage or transfer over a link, I normally instead handle everything byte-by-byte, thereby removing the compiler or architecture differences.

I normally have one compiler-specific header file, and one or more target-specific file.

C++ with inlined functions helps a lot. Alas, that route is rather limited for 8051 targets.

I normally prioritize readability, unless there are strong economical reasons not to. Having a chip with 4kB of flash and a program that needs 4kB+5, and the next larger chip is $1 more expensive and the product is intended to be produced in 10k volume every year, then it's worth $10k every year to make the 5 excessive code bytes disappear.

In the end, I might have 70-80% code that may be reused when jumping to a reasonably similarly sized byt greatly different architecture. Jumping between 8-bit and 32-bit normally have much less reuse - not because of language incompatibilities but because there is normally so big differences in type of solutions selected based on limitations or strengths of the target hardware.