NIST elliptic curves behaving anamolous in OPENSSL benchmark
Here is what's likely going on:


Charm represents Elliptic Curve points in affine coordinates, that is, explicit (x, y) values
When doing a single point addition, OpenSSL adds the two points (internally coming up with a point in projective coordinates) and then converts them back into affine coordinates.  Then final conversion involves a modular inverse operation, and so is moderately expensive (more expensive than all the other operations combined).
When doing an point multiplication, OpenSSL takes the point, and does a series of point additions/doublings, keeping the point in projective coordinates.  Then, at the end, it converts the point back into affine coordinates (which involves the modular inverse).  However, you end up doing a single modular inverse, even though a number of point additions/doublings were done.


Hence, because the point multiplication avoids the intermediate modular inverses, it runs faster than expected.