Users generally don't want to know what's gone wrong, just how to get things working and how to stop the problem from happening again. They don't want to know that, for instance, a specific attribute is not being properly updated when a certain exception is thrown (or whatever), they just want to know that they shouldn't press this button straight after selecting that menu item. It's more of a case of "I just want to use the thing" rather than wanting to know how it works.
By way of analogy (yes, I love my weird little analogies): A driver just wants to be able to drive their vehicle. If second gear is difficult to engage then they'll rev high in first and change up directly to third gear missing second altogether. They don't want to know about synchromesh or whatever, they just want to be able to drive and they'll do whatever it takes to do so.
I think it would help with problem reporting if Scribus had some kind of "core dump" function. It wouldn't need to be anything sophisticated, just something that can be called that "pings" each active class/object to generate a text dump of all attribute/variable contents. It would give the user something they could attach to a ticket that the developers could use to see the current state of the software as it is running. A developer could then scan the dump for any value that looks wrong as a quick check of the "sanity" of the application.
Name : untitled.sla
UOM : Points
Page Size : 200, 280
Type : Rectangle
Position: 20, 40
Size : 100, 50
Line Width : Hairline
Type : Text Frame
Position : 200000, 100
Developer: "Oh, that 200000 doesn't look right". That sort of thing. It doesn't say what the cause of the problem is but it's a pretty cheap way of finding out information that's otherwise hidden.
Anyway, it will be interesting to find out whether a clean installation or a clean preferences file actually fixes the problem. Neither would help to find out what went wrong but it would get the user back on track and, as I mentioned earlier, that's pretty much all they want.