Humor fail, I guess. You guys do realize when someone repeats the same thing over and over with some sarcastic and non-sensical statements, it's not meant to be 100% factual? Right?
The reality is you really can't rewrite CR in ABAP because no one in there right mind would create the UI extensions necessary to create the client side part. ABAP is basically as server side data processing language to create reports, bulk process data, etc not really what I would consider a full featured generic programming language suitable for UI work. It's very similar to COBOL - in fact it's often describe as COBOL on steriods. I mean I guess you could get something like Cobol.Net or RPG.Net, but then you should die in a fire.
Now I've used CR since 2001 or so. And it was what I would consider the best reporting tool on the market until about 2006 - 07. After that time, other solutions began to be on par or better than CR especially if you needed integration with .Net. It might be better on the Java side - I'm a .Net developer so I've never played with the Java components. I will say that the standalone report builder is not really bad, but running the created reports in the runtime is often slow.
Now I suspect the underlying issue with performance on the .Net side is the fact that CR either doesn't know how to develop in .Net or did not want to spend the resources to write a "native" .Net solution. Instead what they did was merely create .Net Interop wrappers around their existing COM objects. That was probably the right call to get a solution out the door really quick, but they should have went back and developed a native solution. If you don't write the wrappers correctly, you get performance problems, memory leaks and other issues. Also realize the CR Merge Modules are/were about 75MB compressed and about 300MB expanded. This puts the client side components on par with the entire .Net 3.5 SP1 Framework and just offers a reporting solution so there is a lot of bloat in there. One of the areas I know they would have duplicated would be the data access components. The .Net Interop wrapper call their C/C++ data access library rather than the .Net functions. If they reengineered their solution, it might end up being competitive for embedded .Net applications. Now maybe the have reengineered their .Net solution since I used it last - I normally uncheck that crap when I install Visual Studio.