Hi Kristian Ekenes ,
Let me try and answer your questions.
Is going from 4326 to 3857 (or vice versa) the typical workflow?
Vice versa is a typical workflow, especially if you want to construct a URL and provide coordinates, most other applications (Survey123, StreetView, Waze, etc) will want this to be 4326 and in many cases you will have 3857. At this point we can use the funtions shared here in GeoNet, but it will be good to have something more decent and precise using the geometry engine.
Or would you require this capability to project geometries to other spatial references?
Normally not (in my case at least), since most of my data is published using 3857 to AGOL. I can imagine the use case of having any other SR in the map and being able to 4326 would come in handy.
Do you see a case where you would write an expression with a hard coded geometry that would be used in more than one web map with different spatial references?
I use it for testing and to avoid creating another hosted feature service with the geometry and having to use FeatureSetBy* functions to get the geometry, so to be honest no. However, a user could have an attribute table or stand alone table with coordinates in a different SR and wanting to use these to create a link to another system that uses 4326.
I have come across several questions in GeoNet, where users have been asking for this functionality or being able to work with geometries in different projections.
Edit: some examples: