I too have seen some pretty long ones such as the one below.
MCM1_ 0002613_ 1916_ 0-- HComputer Valid 3/1/14 18:34:37 3/4/14 03:24:42 28.05 / 28.05 321.0 / 298.0
However, I seem to recall a post by Uplinger which said something to the effect that these are hard to size properly. I do know the overall trend has been gradually increasing in size, but on average may be leveling off.
By the way, on what kind of OS and hardware were your units run ? Mine was on Win 7 Ultimate AMD 9150e at 1.8ghz. 28 hours is an exceptionally long unit for me. I think you are correct that units as long as yours may pose a problem for some crunchers so they at least need to be aware that some units may be quite lengthy. They do checkpoint regularly, so if their cache is not too big, even the slow machines should be able to handle bigger units. However, if their cache is sized for an average of 6 to 7 hours per WU and some big ones creep in, it could cause a problem and send a machine into high priority crunching (panic mode).
Cheers

This may or may not be related but watch out for large differences between elapsed time and CPU time. I've had two occasions now where MCM1 WUs on a WIN XP C2D box had elapsed times almost double that of the CPU time. I've found an OS reboot seems to fix that. Not sure what the source of the problem is.

In my experience, those huge WUs may cause the points/WU to decrease.

If my understanding is correct, the BOINC initially runs bench mark to masure the MIPS/FLOPS to calicurate the elapsed time and points/MIPS. After the initial set, the MIPS/FLOPS are adjusted by actual excution time and estimated excution time. If the actual CPU time is far grater than the estimated time, MIPS and FLOPS initially set may decreased and clamed credit by BOINC drastically decreased.

I have seen this tipe of credit slow down many times. Of couse, this is not only facter to vary the credit, you should watch carfully what is happening.

Kiyo.

Reading your post must have triggered something. I have to wonder if there is a rare memory leak in the MCM1 science. That would result in increased page swapping bumping up IO big time. Since IO is so slow, you end up with lots more elapsed time for the same amount of CPU time. As memory management usually is done with OS level calls, restarting BOINC doesn't help. The OS reboot frees up the orphaned memory. Admittingly I'm speculating here. I didn't sit and watch the IO light blink steadily on my machine when this happened.

I run 3 Core 2 Duo E6610's all running MCM1 on Linux. They have completed about 2300 WU's and the longest one for them has been 22.55 hours. The shortest one has been 2.03 hours. The average time for the units is 6.04 hours. (These figures are courtesy of Piroque's WCGDAWS application.) Maybe it is just the luck of the draw that you are getting the bigger units, but at least they are completing successfully. I see no evidence of memory leaks as these systems have been running months without a reboot.
Cheers