For anyone reading that might be facing the same (or a similar) problem: I think this comment will piece together this puzzle, providing the best explanation of what's going on, plus the workaround that I came up with,
Problem: Inconsistent Display of CMYK Values
It is not possible to manually apply CMYK values as fill or text colors, but it is possible to set these to a CMYK value programmatically via JavaScript.
However, Acrobat produces visibly different colors when doing so. For example,
A button filled with ["CMYK",0.62,0,0.23,0]:


Text filled using the same value, ["CMYK",0.62,0,0.23,0]:


Conundrum: Which Is Displaying The Correct Value?
Comparing the colors to a CMYK color swatch produced in InDesign for the same value, it would appear that the fill is displaying the color correctly whereas the text is not.
But is this really the case?
CMYK and RGB are converted using math formulas, such as those found here.
This means that mathematically, ["CMYK",0.62,0,0.23,0] and ["RGB",97,255,196] are equal. Popping the CMYK value into a color picker will produce the greenish color shown in the text example above.
When I printed the above examples, I was surprised to see that although the Acrobat fill color was the best on-screen match for the InDesign swatch, the best match on paper was the garish green text color. It did not look the same printed - it had more blue tones, was softer, and basically looked like teal should look.
Even when I printed from InDesign, making sure that the right color profile was selected for my printer and that the printer's driver did not override ID, the color was not a close match.
Explanation (so far...)
["CMYK",0.62,0,0.23,0] and ["RGB",97,255,196] are only equal if using the same conversion factor. The ones found on EasyRGB seem to be commonly used for the web and HTML. How a color is converted depends on the color management system, and clearly ID's color management differs.
My current theory for why fill and text color look different in Acrobat is that Acrobat's color management system treats fill and text colors differently. It seems to treat CMYK fills similarly to how InDesign treats CMYK values, but Acrobat treats CMYK text differently - in this latter case, it appears to use a different algorithm.
If this is not the reason why the colors look different, then I have no idea what is. It is not because the .textColor property is being converted to RGB. I tested this by setting the .textColor to ["CMYK",0.62,0,0.23,0] and then using the console log to retrieve the color of the text. It retrieved, "["CMYK",0.62,0,0.23,0]". If it would have been converted "behind the scenes" by Acrobat, then the console should have retrieved an array containing RGB values.
In reality, all colors that we look at on a computer monitor are RGB colors. The only time we actually see a CMYK color is when looking at a CMYK print.
Workaround
What I'm doing so far as a workaround is to set different colors for viewing and for printing.
Basically, I am using InDesign's color management to convert CMYK colors to RGB and then setting both the .fillColor and .textColor properties of the fields that I want to color in Acrobat with this InDesign-generated RGB value. This seems to produce the most consistent colors across the two properties, i.e. fills and text end up looking the same color.
By printing the document with the RGB values, I can pinpoint which colors are too drastically different, such as the teal, and focus on a workaround for them, ignoring the rest to try and reduce workaround time.
When it's time to print, a "Document Actions" script assigned to "Document Will Print" can change all problem colors to CMYK before printing (you can, of course, opt to convert all colors to CMYK - perhaps this will make the document more consistent or at least more predictable across different printers).
I tested this with a sample and it worked.
The catch here is that it changes the colors for the print preview. If your users are expecting the print preview to match the form that they see on screen, they will need to be notified that the colors will look different but should print correctly, so that they are not alarmed when they see how the colors have changed on the print preview screen.
Warning*** this workaround is tedious*** but it works. If you try it, make sure to check your results in print and tweak accordingly.
Update: Just wanted to add that instead of changing the color of the fields programmatically before printing, you can also experiment with using scripts to convert color, such as colorConvertPage(), or set color profile/Preflight, etc. on a Document Will Print script.