There are two general reasons to avoid tiny coordinates (or tiny differences of coordinates). Because I cannot (readily) find any PostGIS documentation about its internal storage format for coordinates, I will give them both.
Many GISes convert coordinates into indexes into an extremely fine grid of points covering a study region or "area of interest." This enables them to do all geometric calculations using integral coordinates (just row and column indexes). Textbook algorithms can be used almost unchanged when integral coordinates are involved; storage requirements may be halved (an integer takes four bytes while a double takes eight bytes); and possibly the calculations will be faster on some processors.
Using four bytes (=32 bits) for integer values limits these grids to 2^32 rows and columns. For geographic coordinates, values up to 180 in size may have to be stored. So that the grid can cover such an extent, the interval between neighboring grid points cannot be any less than 180 / 2^32, which is about 4.2E-8. Values between -2.1E-8 and +2.1E-8 therefore would all coincide with each other and with 0.
Whence, if there is any possibility that your data might be processed by a GIS using integers for its calculations, you cannot rely on it distinguishing numbers like 1.2E-15 and 1.31E-15 from each other.
Double-precision floating point issues
I suspect this is not the problem, though. Although the error message is strange, one interpretation is that PostGIS detected a self-intersection during sequential processing of the polygon coordinates and the detection occurred when it was processing (-180, -90). This means it thinks (somehow) that there is a problem with the first two edges.
The equations to compute a self-intersection come down to inverting a matrix. The matrix coefficients in this case are
This matrix is extraordinarily ill-conditioned: its eigenvalues of -180. and -5.5E-17 cover 18.5 orders of magnitude, giving a condition number of 3.3E+18. This enormous condition number means that numerical procedures to invert the matrix will be unstable, even with double precision arithmetic. It is likely this instability led to a spurious intersection of the first two edges of the polygon, resulting in the error.
18.5 orders of magnitude is greater than the 16 to 17 significant figures of precision available with double precision floats. In effect, all bets are off concerning what solution the software will find.
When E-15 is changed to E-12, the condition number drops three orders of magnitude. This time the software can find a solution--but probably only to one significant figure. Perhaps by accident, that solution does not indicate a self-intersection. But you're not out of the woods yet: one significant figure is terrible precision for GIS work (or almost any other numerical work). There will be concern about these precision issues until the E-15 is increased to around E-6 or so. The latter value represents about 0.11 meter (at the most): see http://gis.stackexchange.com/a/8674 for how this distance was computed. For almost any application, getting a precision of 0.1 meters when mapping at the scale of the entire earth is more than good enough.