The original question was about “additive” versus “translucent” blend modes. Both of those modes require reading from the framebuffer, performing math (which is generally fixed-function,) and write-back to the framebuffer. Further, because the math may be order dependent, the renderer cannot hoist the render order of triangles around the pipeline. (This was huge on some mobile tile renderers; don’t know how much this still is a matter on the latest hardware versions.)
Now you’re suggesting screen-door transparency instead, which is a totally different mode. Screen-door effectively treats the “blended” pixel fragment as either on or off, and writes it or doesn’t write it. Note that this doesn’t require any read-back from the framebuffer to composite the value. However, framebuffer interfaces may work like real cache lines these days, which means that you pay the read-back penalty anyway unless you overwrite the entire “cache line” (which typically is a pixel block of some size — between 2x2 and 4x8 depending on hardware.) And then you have to consider early Z effects as well.
All of these are quite fiddly bits that are highly situational. On some kinds of hardware, for some scenes, temporal or screen door transparency can be a win. On other hardware, or for other scenes, it may do nothing but make your art look bad. If you are not fill rate limited, then it’s unlikely to matter at all – if you spend 300 cycles shading a pixel, that is usually way more than needed to hide the additional latency of blend modes.
It doesn’t help that each new hardware generation does this differently, and changes the rules even within a single vendor. The only way to know for sure whether it’s worth it, is to carefully benchmark your particular art and scene on your particular target hardware with your particular circumstances.