This is a a known issue with ACES. The whole system is built around using scene-referred values with plausible reflectance values. So imagine the value a pure white graphic would have to be in the real world for it to be recorded by a camera and still come out looking like pure white on screen. This is the reason your whites look crunchy, they’ve been converted, I presume with a reverseODT, to work in ACEScg but this puts the whites at some extreme value way above float 1, probably something like 11 or 14. Now your anti-aliasing doesn’t work as well at these values and so the crunchy edges on white text.
If you want to stay in ACEScg technically you would use the Utility-sRGB-Textures IDT, but as you’ve noted the graphic would come out dim, because all that does is put an sRGB image inside an ACES container, basically replicating the reflectance values if you recorded an sRGB graphic off a screen.
Also note that all conversions in ACES use 3D luts, so even if your graphic looks ok in ACEScg, it technically won’t be the same as the original sRGB. Also there is another known issue with desaturation of very saturated yellow colors, again a known limitation of the system. When the system was originally developed the use case for graphics was never considered because, graphics don’t “exist” in the real world!
The best approach for simple graphics…don’t work in ACEScg, unless the graphics live in some rendered world with plausible reflectance values. For simple graphics where we need accurate representation of client branding standard linear is fine as the elements are only processed with a straightforward and accurately reversible gamma operation.