Adam -- the only reason I can surmise, which I'll admit is conjecture, is that if the index is never discarded, there could be the possibility of introducing corruption to the view itself or possibly the design; otherwise, it is probably a disk-management issue as you indicated.

I know of several tax-based or financial apps that are critical for two months a year, then go dormant the other ten months ... and they are quite large. So, it is possible for them to have a view go unused after that 245 day window.

Two possible work-arounds:
(1) Perhaps, to avoid the situation you mention, setup a program document to run updall -R <view_name> on the 244th day or nearest Friday evening/weekend ...
(2) or just setup a repeating reminder on your team calendar that will cause you to use the view--every 240 days. Then, the view index would remain. Yes, this is sub-optimal, but would help alleviate the problem in the near-term.

Good luck.

@Bill Thanks for the feedback

Yes - not sure why an view index that wasn't opened by users would be any more likely to corrupt than a frequently used view index.

For workaround - I didn't think "-R" "resets" the discard index counter. (I thought this only happened with user access/@DBlookup/@DBcolumn - but may be wrong) . I know it won't do anything to a view that already has dropped its index.

I do know that a scheduled "updall -C" would keep all view indexes in the db built w/o having to specify db name. (and potentially chew up disk)