This is a common problem with floating point numbers. In general, you cannot rely on floating point numbers to be "rounded" to any precision unless the rounding is actually part of the program logic or underlying language/library. This happens with whole numbers used as floating points, too. For instance, 39 might become 38.999999999999, which can be a real problem if not handled correctly.

Small differences in rounding occur because floating point numbers are stored in a relatively small region of memory, and the mantissa and exponent are stored as powers of 2, rather than powers of 10, as you see on screen if you just print it out. As such, it's very improbable that a given number in base-10 (decimal) arithmetic will have a base-2 (binary) equivalent that gives the exact same number. The number will be close (yours broke on the seventeenth significant figure), but rarely exact. DBI and SQL Developer are likely clipping off spurious digit(s) from the result, while ASE is not, or it could be differences in machine/data architectures.

Do you actually need 17 significant figures, as your example indicates? Or do you just need the results to be the same across all tools? If it's the former, you will have to rethink your data design to include larger floating point numbers (larger means more precise with floating point). If it's the latter, I would just round the result off to whatever precision you need (and can safely expect to maintain).