Welcome to these Forums!
There's no need to convert the radians to degrees, nor to make lists of angle categories and the colors to go with them. You can do the whole thing directly in radians, and figure the required color number based simply on dividing the Text's rotation angle by 45 degrees [with compensation for the facts that your first color number is 3, and that you want the 45-degree multiples to be the start of a range, rather than the end of one]:
(defun C:TCR (/ ss n tdata trot); = Text Color by Rotation
(if (setq ss (ssget "_:L" '((0 . "TEXT"))))
; User selected Text object(s) [on unlocked Layer(s)]
(repeat (setq n (sslength ss))
(setq
tdata (entget (ssname ss (setq n (1- n))))
trot (cdr (assoc 50 tdata)); rotation [in radians]
); setq
(entmod
(append
tdata
(list
(cons 62
(+ 3 ; [to start first 0-to-<45 category at green]
(cond
((equal trot 0 1e-4) 0); exactly 0
( (or ; exactly at octant crossover direction
(equal (rem trot (/ pi 4)) 0 1e-4)
(equal (rem trot (/ pi 4)) (/ pi 4) 1e-4)
); or
(1+ (fix (/ trot (/ pi 4)))); [start next color]
); octant-direction condition
((fix (/ trot (/ pi 4)))); all other angles
); cond
); +
); cons
); list
; will replace earlier 62-code [color] entry if present
); append
); entmod
); repeat
); if
(princ)
); defun
[That (or) test with (rem) functions in it is because sometimes the remainder from dividing a 45-degree-multiple angle by 45 degrees turns out to be essentially 45 degrees [only a few gazillionths less than that], rather than essentially 0, on account of tiny differences many decimal places down in the number as it's stored or calculated. I have found this kind of accommodation necessary before in determining whether an angle is a multiple of some reference angle.]
Kent Cooper, AIA 
I find that @Ranjit_Singh2's routine doesn't put a 45-degree multiple direction at the start of a new color category, but at the end of one, which means in my test arrangement you don't get equal numbers of objects in each category:
It could be the same way-down-decimal-places issue that I used the (or) function to get around, or [I didn't evaluate carefully] it could be written without taking into consideration this from Post 1:
=>0 and =<44 assign color 3, =>45 and =<89 assign color 4, =>90 and =<134 assign color 5 etc.
which I took to mean that anything greater than or equal to 45 degrees would be color 4 [but it came out color 3], and similarly the 45-degree multiples would all be the start of a new color. [Post 1 doesn't really address what to do between 44 and 45, and between 89 and 90, etc., but I assumed those would fall in the under-45 or under-90 class.]
Kent Cooper, AIA
That one has the same issue:
and it doesn't start with color 3 [easy enough to compensate for], and somehow it doesn't change the color of the last two [I started out with them all at arbitrary but visually distinguishable color 30 -- the orange -- just to confirm in my own routine that existing color overrides would be changed as well as no-override ByLayer color, and those two remained at color 30].
Kent Cooper, AIA
@john.uhden wrote:
Thanks for the testing. I hadn't tried Kent's polar array testing.
It was driving me nuts as my selection filtering would not find text with rotations between 335ยฐ and 360ยฐ.
The solution was to change the range limit to 359.99999999999999ยฐ, which I guess is close enough.
You are up against exactly the issue described between the code and the image in Post 8. The evaluation in my routine looks at each object's rotation after selecting all of them, and it's not too hard to compensate for that possibility, as I've done before in other routines. To apply the same kind of thing in selection filtering to select the objects separately for each range would probably require some -4 entries with OR or less-than-more-than evaluations. I imagine the workaround you describe would occasionally result in something being determined to be in the wrong category from the "other side" of that decimal divide.
Kent Cooper, AIA