The behavior is correct for the way you worded the query. Kinda like English - punctuation in different spots can change the meaning of a sentence. Alternatively, it is sort of like being told to take a truck to pick up a package at the hardware store. Having been told to take the truck, you expect it to be kinda big and kinda heavy - so you drive around by the loading dock......only to have to walk through the store to customer service desk to pick up an envelope.
In your case, the preprocessor looks at the query and determines by looking at the query construction that it might get multiple rows back - hence it goes for a LOP of group by (because you told it to) - for example, @Key could have a 'string%' in it and the operators could be >, <, Like, etc. In fact, the very presence of the 'group by' tells ASE that you expect multiple rows - just like a 'distinct' would tell ASE that you expect multiple values with duplicates that it needs to sort/eliminate the duplicates out of. All of that is before optimization even begins.
If you know the value of Key upfront as @Key, the simplest expression is the scalar max() without the group by.