I know I am coming late to the party and thanks for Doug’s contribution towards wrapping this.
For history purposes, there was a long early conversation about ‘Alpha’ in ACES and in OpenEXR
when we chose it for ACES.
Because of the complications of alpha handling (associated (a.k.a. pre rendering) or not-associated) and
that pre-rendering should be removed from almost all color operations before you do them – it is only a few cases where it makes sense to do it on the combined value, the assumption for CLF was that it is only
unassociated color components being worked on. I can see that there is no use of the word ‘alpha’ in the document.
I would note though that it was anticipated that a 4-channel component image might be passed through, and so the 4x4 matrix was included (generally with an expectation that only the 4,4 element would be used and that it would be 1.0 for alpha channels) It also covered the CMYK conversion cases if needed. Note the discussion of the ‘extra’ row/column as being an offset for the 3x4 case.
However, the Conventions section says normal operation is only 3- components (so alpha is not included on purpose).
I agree that it should not be in the spec. I can see a note being needed that color components should be converted to unassociated with alpha (and alpha then recombined in the application if desired to preserve it. I think that this was also part of the issue with adding an Exponent node or a LogNode. Ideally, alpha is only a coverage matte – however EXR uses it also as an additive offset in some cases. So yes, dealing with Alpha can get messy. (so it was punted out)
If it is essential to deal with cases like on-screen graphics and real-time conversion for such, then we might need to look at extending to cover it – but I agree that it needs to be a first-class 4-th channel that may have it’s own ProcessList different than the color components. sigh.
I still vote for Punt. 
Jim