I can't speak for others here, maybe they see it the same way that I do, if not they can speak up.
This sort of coding is very very fragile, and when my code gets anywhere near this point, having "evolved over time", I sit down and rewrite it to make it safe
All the IF this and ELSE that with hardwired bits & pieces are OK whilst they are few in number, and simple, but once they grow to a point of potential failure I replace them with a JOIN to a lookup table, or a set of structured rules. That takes time to do, is not cost-effective when its only a couple of simple items, but sure as eggs-are-eggs it is cost effective the moment the issue becomes complex.
Albeit that I don't understand this particular problem fully, mainly because I don't have any core-skills in SSRS, my gut feeling is that it needs sorting out with something much more robust than a hideously complex set of nested IIF statements. IIF Functions are a ghastly solution compared to something more structured. "More structured" brings with it better readability, much higher chance of spotting bugs, easier debugging, and so on. Going one step further and building Lookup Tables and/or Rules Tables means that the data stored in them is forced to be uniform (by column datatype, length restrictions, and quite possibly also by validation rules on any data added to the lookup tables) and is also a lot more robust than (IF MyColumn = 'XXX', 'YYY', 'ZZZ') where XXX, YYY and ZZZ are only as good as I typed them, hardwired, into my code.
At the very least these IIF statements could be recoded and encapsulated in a VIEW which would make it much easier to "test" that they were performing as-intended, and be reusable across any number of queries / reports - i.e. the logic would be centralised.
Using multiple CTEs or CROSS/OUTER APPLY statements would allow the code to be developed [in a VIEW] iteratively and, I fully expect, more reliably