Aside from portability, ROWS also redefines the purpose of the widget set. It provides an interface to graphical devices - not X, not a bitmapped screen, but any device that can be addressed using 2D vector command. This means that, for example, in a wordprocessor, the code that renders a document on screen will be just as capable of rendering on a printer. You could even render the contents of a dialog box on paper if that was what you wanted to do. The graphics commands are the same, and the coordinates are the same (ROWS measures in millipoints, not arbitary pixels)
Of course there are other standards problems that ROWS addresses too - there are many font formats, rendering methods and names. There are many 8-bit encodings (so ROWS uses Unicode throughout). There are many interchange standards (ROWS will do its best to support a general model for these)
The upshot of all this is that you can write a POSIX-compliant application with ROWS, and expect it to work on all the systems that ROWS works on. To be capable of running ROWS, a system needs to comply with POSIX to a certain degree, have a windowing graphics system and a decent C compiler.
C++ is very similar to C, though. There are various ideas for making a C++ interface to ROWS, either through the usual 'write a wrapper' method or by writing a C to C++ converter. A widget heirarchy is naturally object-orientated, and a converter that understands the design of ROWS could probably convert most of the functions with little or no help. Of course, it won't be completely easy to write, but...