Your "should be functions" suggestion is far more problematic than aspect-ratio.

   div {
     width:100px;
     height:100px; 
     aspect-ratio: 3 / 2;
   }

In your first example (shown above), aspect-ratio has a clear way to solve conflicts: aspect-ratio does not overwrite explicitly defined dimensions, it can only affect implicit dimensions.

Your suggested replacement does not. What happens in the case below?

   div {
     width: height(100%); 
     height: width(66%);
   }

Problems with the function approach that I can think of off the top of my head:

1. There is no logical way to say that one function should override another in the case of circular constraints.

2. It relies on percentages instead of fractions, this leads to developers having to either needing to nest an extra calc function within to deal with a fraction, or rely on precomputed magic numbers which are never a good thing. The new aspect-ratio rule means new developers will never need to commit the fact that a height of 56.25% the width results in a 16:9 ratio. If we're using a fraction instead, why create two functions that fall prey to the other problems listed instead of just putting it on `aspect-ratio`.

3. Naming collisions. Something perhaps best avoided, lest we encounter strange lines like: `height: height(var(--height));

4. It relies on percentages for widths and heights. This is just going to add more even confusion about the conditions and gotchas pertaining to percentage units on the width and height properties. For example: `height: 56.25%;` sets its height based on the width of the element (unlike `width: 56.25%` which sets it width based on the width of its containing element) except in the cases of various `position: absolute;` and `position: relative;` caveats on the element in question and its parents.

5. It relies on using widths and heights instead of focusing on lengths along inline and block axes. What happens when the writing direction changes to vertical? Do the widths and heights switch or not?

The aspect-ratio approach is fine. In fact I'd go out of my way to say it's better than fine. All the problems of different approaches presented and debates held during the formation of the standard have resulted in a great css addition that removes many annoyances that developers have had with no additional downsides.