Granted that is still not much but here I've augmented the 546 byte example to render nearly the same results with only 155 bytes. 
I've removed rem units as it's easier for all to understand without them. Pixel units scale just fine across the browsers available these days so there's no need for the mental hurdles and explained calculations. I've left them in the source HTML all the same for the sake of testing. The real feature making sites look good across a ever widening array of pixel densities today is this meta tag that was also used in the example HTML: <meta name="viewport" content="width=device-width"> 
Setting a font-family generically on the body tag gives the shortest path to consistent, doesn't-look-like-times-new-roman, font styling possible.
I left the unmentioned line-height in because it's a good default. It adds a little basic spacing between wrapping lines of text.
Styling elements that are children of the article to only have bottom margins gives consistent spacing to all content, and since top margins collapse  we can avoid dealing with them all together.
Anyways, what you've written here is good, and definitely encompasses some things I thought about. Two notes for you:
1. I explicitly preferred Arial and Helvetica over the generic sans-serif is because I found some other popular web safe fonts didn't look nearly as good, for example, Open Sans, mainly due to the large x-height.
2. I don't think rem incurs much cognitive overhead over px, and the main reason is that it scales with the user-adjustable font size. Try changing your browser's font size from 16 to say, 20. You'll notice that with px max-width, # chars per line will decrease a lot, affecting readability. in contrast, rem max-width will scale nicely.