Assuming one wants to write a specific solution, rather than a general one, sure. And when you want to deal with an unnamed array returned from a function? Well, you can throw *that* in a CTE to give it a name, or perform some other such contortion. The aggregate load of having to phrase such simple ideas in complicated ways really isn't good.
None of what you are saying is likely to ever see the light of day. If you want to learn the SQL-way might be easier to just forget about your idealized equivalency between composite types and array containers.
The problem with "easier" is that addressing directly in front of you is always easier in the immediate sense than actually attacking the problem itself. It also dooms you to the (after)life of Sisyphus, always rolling the same rock up the same hill.
ARRAY[...] is a constructor, its output is an array container. You can either type the elements within the constructor or leave them untyped and put a syntactical-sugar cast on the result.
ARRAY['2023-01-01'::date,'2023-02-01'::date]
ARRAY['2023-01-01','2023-02-01']::date[]
While you've said that having all this stuff would "be quite handy" that isn't obvious to me. It is even less obvious that any benefit would likely be small compared to the effort to make all of this actually work.
Well, making one small part of it work would be a boon to me. Is a simple, generic cast from an array to a record really rocket science? I can't imagine why that would be.
Even if I could write: composite_type[1] instead of composite_type.column1 I don't know why I'd want to give up the expressiveness of writing the column name.
Naturally, you wouldn't give up the ability to do that. You'd merely gain the ability to do it another way.