Well, some of that might happen eventually. In the meantime, happy digging
We moderators can't do much about it.
1. Macros, functions, classes, whatever - most of the time it seems to that one is just digging in the weeds at that point. As a hardware designer, I don't care most of the time, unless I'm trying to make stuff run really fast - in which case it all seems to come down to direct port manipulation, arrays, and SPI tranfers.
2. "having macros that save us from needing to know too much about the hardware addresses" was the main goal I think, making it easy for hobbyists/artists.
Getting folks to make the jump from
byte redButton = 2;
pinMode (redButton, OUTPUT);
that is, using descriptive names to describe the hardware, seemed a big advance to start.
Software name "2" on the board mapping to physical pin whatever being actually connected to IO port D, bit 2, on some chip types despite being on 2 different physical packages, and to another port/bit altogether on another chip type, that seemed really clever to me.
3. I think there are bit read and write commands. byte read & write are not so handy until you get to the bigger chips (1284, 2560) where whole bytes are actually brought out. I struggled with that to start, not having a complete 8-bit port usable on the 328P designs - serial got in the way, crystal got in the way, not all pins were brought out, etc. As I got into serial/SPI/I2C transfers, I kind of got over that. And eventually got into usingAtmega1284P instead to have 32 IO and whole ports to use for stuff.
4. int led = 13; yeah, just bad example to start. I use byte myself, some use const & define, most times its just digging in the weeds. There's a whole website on the avr gcc compiler, everybody says the compiler does a pretty good job, so I don't worry much about it except when I'm really going for speed.
As Monty Python might say - is this the 5 minute discussion, or the full half hour?