Every set of coordinates stored inside SDE.ST_GEOMETRY is stored as a compressed array of 8-byte long integers. The IEEE floating-point to integer conversion is performed by subtracting the coordinate reference X_OFFSET (or Y_OFFSET, or Z_OFFSET, or M_OFFSET) and multiplying by the XYUNITS (or Z_SCALE or M_SCALE). The process is reversed when querying for coordinate values (divide by scale, add offset). The difference between the original value and the stored representation will not exceed half the multiplicative inverse of the scale factor.
The slight difference you are seeing may have been introduced in IEEE floating point representation, when a mantissa which is not evenly divisible by two causes rounding at the fringe of the least significant bits, or it could be due to choosing a coordinate reference scale which is not a power of 10.
In my ArcGIS 10.2.2 instance, the 4326 SRID XYUNITS is one billion (10^9), and following your procedure shows the same precision out as in:
SQL> SELECT srid,x_offset,y_offset,xyunits FROM sde.st_spatial_references WHERE srid = 4326;
SRID X_OFFSET Y_OFFSET XYUNITS
---------- ---------- ---------- ----------
4326 -400 -400 1000000000
SQL> create table foo(objectid number(38), shape SDE.st_geometry);
SQL> insert into foo values (1, SDE.ST_GEOMETRY('point(1.2345 1.2345)', 4326));
1 row created.
SQL> select SDE.ST_X(SHAPE),SDE.ST_Y(SHAPE) from foo;
If you are capturing the coordinate values in a 'C', Java, or Python API, the slight difference in formatting (which is no more than 3.4 nanometers at the equator) may be an artifact of your choice in formatting (I use
log10(scale_factor) digits to the right of the decimal when the log10 is integral, and
log10(scale_factor) + 2 when it isn't).