Whew... false alarm then... I was scared to death by a thought that Corona in Max would stop saving EXRs with premultiplied alpha.
Nothing has changed there. Saving to non-CXR formats in VFB is being done by Max.
But notice that it DOES NOT premultiply by alpha (and IMHO it never did). One can easily try it: render a scene, inspect some pixel having alpha between 0.0 and 1.0 with VFB's pixel probe, take the tone mapped float red value, and power it to 2.2. You will get a value of a red component in that pixel after saving to EXR (you can inspect it with CIE, for instance). If you further multiply it with that pixel's alpha (which what the premultiplication is), you will get a different value than Max has stored. That implies Max does not premultiply. And yes, CIE in the "original" column shows truly saved values for just opened EXRs.
Anyway, I still think you got it upside down. If it works like in 3ds Max, then it does store images with premultiplied alpha, not without it. Even official 3ds Max documentation says so: https://knowledge.autodesk.com/support/3ds-max/learn-explore/caas/CloudHelp/cloudhelp/2015/ENU/3DSMax/files/GUID-E49782BE-6486-4B9D-929A-7A02535F1829-htm.html
Yes, I know that article. IMHO it is a lie because they do not do it, as far as I can tell.
And images outputted from 3ds Max indeed have correct alpha when loaded into compositing packages, just like images from any other software that use premultiplied alpha.
Premultiplied alpha is not about the alpha channel itself. Premultiplication means "take red/green/blue and multiply it by alpha, then store results + the alpha itself". Nothing more. It changes colors and the loading software must be aware of this and handle it properly. The difficulty is that from an image you cannot tell whether it has been saved premultiplied or not. That is why image formats define it - like EXR, the standard expects its data to be premultiplied. But nobody seems to follow it. We have decided to ignore it too - in our custom saving handler, used in CIE or Standalone, because of the others. The premultiplication brings more troubles with actually zero benefits, see below.
Afaik it is not an optimization, but a means of ensuring that images with alpha channel compose on top of each other correctly in post.
It is, as you can see from the above described principle - one can do it any time later. So any composing software can do it while it is actually composing. Technically, it is not required to do by every image producer.
The premultiplication is just a trick how avoid one multiplication per pixel while composing images on top of each other. It is an often done thing and in old times it made sense to save the data already premultiplied so it wouldn't need to be done every time using the image. But with performance of today's computers, plus/minus one multiplication per pixel makes no difference. On the contrary, the premultiplication brings troubles and misunderstandings like this. Unfortunately, EXR authors have decided to stick to the old times in this. I don't know why and from my perspective it was wrong.