The twip is the unit of measurement that defines dimensions in an RTF document. There are 1440 twips to the inch.
The reason you need to bother about the twip is not so much what it is, but how it is used. The key fact to remember is that in an RTF file, dimensions are measured in whole numbers of twips. Therefore, the twip defines the inherent precision in an RTF file beyond which it is impossible to improve.
This goes some way to explaining the slightly odd definition of the twip. By defining the twip as 1/1440th of an inch, it is possible to express all "reasonable" fractions of an inch (or points) as a whole number of twips. For example, half an inch is 720 twips; a quarter of an inch, 260 twips; a thirty-second of an inch, 45 twips. Thus, when dimensions are expressed in inches, it's likely that their representation in the RTF file will be accurate.
This is not true when dimensions are expressed in centimetres.
For example, 6cm is (approximately) 3401.5748 twips, which can't be represented exactly in an RTF file. Try it. Create a table in Microsoft Word. Set the width of one of the columns to six centimetres. Save the file as an RTF document, and open it in a text editor. Search for the string \clwWidth. [This is (one of) the command(s) that defines a cell's width.] Its value is 3402, or 6.00075cm.
Admittedly, this difference is completely irrelevant for most purposes, but when working with pagination issues, it can be important. For example, if a text is 6.0005cm long, it will fit in the cell, but the SRSPaginator will say that it will wrap onto a second line. Thus, an inaccuracy of less that 0.00025cm in width will cause an inaccuracy in height equal to the height of the text: a far greater amount.
Therefore, to ensure the highest possible accuracy, you should use inches or points when specifying column widths in a SAS program that creates an RTF document.
OK, I know I've ignored the cell padding in the example above, but you get the point.