Take a walk and slow down on everything.

Can spatial types be used to store the dimensions of 3-dimensional objects?

Yes, of course ST_MakePoint takes a Z cord (and even an M cord, hello time!)

Money is made of dollars and cents, but stored as one field because dollars and cents are properties of the same value, not values themselves (you can use simple math to convert between the two). Weight is made up of pounds and ounces, but is also stored in a single column for the same reason. [...] Likewise, it seems that x,y and z dimensions are really just one value as well, with three properties since there is little need to know x without y and z in an application (but you may want to query on them discretely).

Dollars are a unique function of cents; pounds a unique function of ounces (x,y,z) are nothing like that. They're three coordinates for discrete spatial dimensions.

You could store dimensions in a varchar with a delimiter, like 7;4,2;2, but this would make any queries for certain values difficult. ie. "get the record that has the longest (any dimension) side".

There is no point in reinventing the wheel. You could store them a lot of ways. They tend to be stored something ISO/IEC 13249-3:2011, detailed in PostGIS.

Of course, the conventional approach of storing x,y, and z in separate decimal columns would also have issues with a "get the longest side" query, since the database wouldn't treat them as one value collection. (You would have to get the longest of each, then the longest of the three results).

Why would you call this the conventional approach? You find it intuitive because you've never used GIS so you call it conventional? The conventional approach to store (x,y,z) is with a spatial 3d type.

Can spatial types be used to store the dimensions of 3-dimensional objects?

Yes, of course ST_MakePoint takes a Z cord (and even an M cord, hello time!)

Money is made of dollars and cents, but stored as one field because dollars and cents are properties of the same value, not values themselves (you can use simple math to convert between the two). Weight is made up of pounds and ounces, but is also stored in a single column for the same reason. [...] Likewise, it seems that x,y and z dimensions are really just one value as well, with three properties since there is little need to know x without y and z in an application (but you may want to query on them discretely).

Dollars are a unique function of cents; pounds a unique function of ounces (x,y,z) are nothing like that. They're three coordinates for discrete spatial dimensions.

You could store dimensions in a varchar with a delimiter, like 7;4,2;2, but this would make any queries for certain values difficult. ie. "get the record that has the longest (any dimension) side".

There is no point in reinventing the wheel. You could store them a lot of ways. They tend to be stored something ISO/IEC 13249-3:2011, detailed in PostGIS.

Of course, the conventional approach of storing x,y, and z in separate decimal columns would also have issues with a "get the longest side" query, since the database wouldn't treat them as one value collection. (You would have to get the longest of each, then the longest of the three results).

The conventional approach to store (x,y,z) is with a spatial 3d type.