Performance issues aside, reputed by whom? Based on what data? I've seen so many beliefs like this over the years about SGI parts, systems and sw issues, but they mostly seem to be self reinforcing over time rather than based on hard data. That doesn't mean they're not true of course.

But many beliefs have become out of date as components age, etc. I know of one example which was my fault, the belief that 6.5.15m was better for the dmedia libs, it spun off from a comment I made yonks ago about bugs in 6.5.16 (but they were fixed in a later release, so the notion about 6.5.15 quickly became null).
If anything I've had more problems with R10K boards than R8K boards for Onyx/Challenge, but is that because of pure chance, random bias in sample size, the fact that fewer people ask about R8Ks so I put them in systems less often so they're not stressed as much? All sorts of possibilities. It's a mess of selection bias; often something that may have at least a grain of truth becomes exagerated, such as the commercial belief that 1327 mbds for O2 are "better" for serial port I/O (I've heard this from numerous medical and industrial corps, but none can provide a justification or data proving it, none have actually tried a 1227 to compare because they're not allowed to).
So in the end it's hard to answer the first question there because none of us have much to go on beyond the anecdotal and personal experience, neither of which are a sound rationale. Maybe it's a batch issue, perhaps some R8K modules for Indigo2 had issues and those are the ones which gave them a bad rep, whereas most might be as equally solid as an R10K. It would be great to have SGI's old warranty/repair claims data for all this, but I guess that'll never happen (probably been lost by now anyway). My hunch is R8K likely is less reliable in Indigo2 than R10K, but by what degree I couldn't say, nor how it might compare to R8Ks in Challenge/Onyx. For some performance background, see:
http://www.sgidepot.co.uk/sgidepot/r8kcomments.txt
Re the switch to an R4K/200, that in just about every way possible which matters would be an upgrade. 8) The only thing for which the R8K would be better is highly optimised FP64 of a kind that's properly suited to R8K (see above link), but even then in Indigo2 the halved L2 size limited the gains compared to how R8K behaves in Challenge/Onyx, with perhaps the lower memory bandwidth being a factor aswell. The SPEC results for R8K showed the widest variance for any CPU I examined, it's all over the place, while for general integer performance (which matters for 3D aswell re table lookups and pointer chasing) it's rather poor. For unoptimised FP32 it's less than half the speed of an R5000SC/180 for the Blender test (I suppose one could say that's not too bad given the low clock speed, but remember the cost involved with R8K), sitting last in my table atm (an R10K/150 O2 is more than 3x faster):
http://www.sgidepot.co.uk/perfcomp_RENDER1_blender.html
Without code optimisation the R8K was not a good fit for Indigo2, but I expect some places did the relevant work and got good use out of it, especially those that had already done the work with the big iron (I know Chevron in Nigeria had an R8K Onyx rack, but by the time I talked to them they were already using Octanes for desktops which they thought were awesome).
Ian.