Outlook overrides your colours by either editing the inline style or if it's added with CSS they add an inline style.
So this <p style="color: green">text</p>
Becomes this <p style="color: rgb(103, 202, 82);" data-ogsc="green">text</p>
I've not yet found a way to prevent this from happening but you can override it by adding styles to your head.
Because they are only touching inline styling and not your <style> block you can add something like p{color:green !important} which will override the added inline styles.
It could end up being quite a lot of code doing it that way if you're using a lot of colours so may be best to only use it where the changes are really bad.
The general rule I follow is keep individual images under 500kb and total email size (all images and HTML) under 1mb. You can go higher but I think you need a strong use case and be mindful how the email looks while it's loading, is it still useable?
Remember you can still get a slow connection, even in the center of a major city.
Outlook conditional comments don't apply to mac only Windows so you're already doing it :)
You could try @supports (position:absolute){}
Or something like this (may have more support but I'm not sure), set the elements in the HTML but hide them
<div style="position:absolute:display:none"></div>
Then target that with CSS and it'll only display them if the position hasn't been removed. And add more styles you might want there.
[ style="position:absolute:display:none"]{display:block !important;}
Try applying the class to a <div> rather than a <td>.
Yahoo is probably adding something to the table to mess it up table {width: auto !important;} maybe.
The class is on the <p> tag but you're trying to change the <a> color. You could either move the class on to the <a> or change the selector to target the <a>
.links-read a:hover { color: #4471c3 !important; }
Generally the advice is don't use aria, use semantic code instead. Unfortunately that's not always possible, so to fill the gaps we can use aria.
I'd suggest listening to your email with a screen reader (this in itself is a skill and can take a while to get used to) if anything doesn't make sense, first off try and fix it with regular text, if that's not possible you can use some aria.
Think of using the screen reader as a way of proofreading your content. i also think this should be part of everyone's QA process.
The majority of emails shouldn't need anything added, and it's always best to be sparing with it.
From our testing all those units you've listed px, pt, em, % all work across the board.
From an accessibility point of view em or % would be best as they would scale with the user settings where px and pt do not.
The only issue with em and % is they are based on the parent font-size so could cause issue if used with a nested component build system.
In this case rem would be better as that is only relative to the root font-size. Unfortunately rem doesn't work in mso Outlooks but you can define a px fallback quite easily font-size:16px;font-size:1rem.
Hope that helps.