In the API v2, GET /observations/{uuid} returns almost the same information as GET /observations. it looks like the main (only?) difference in the response is that GET /observations/{uuid} will return non-traditional projects associated with the observation (when the observer is a member of the project). (meanwhile, GET /observations allows filtering by a much larger set of parameters.)
I could see in v1 where all fields were returned why you might want to have a more limited response for GET /observations, but now that v2 requires the user to specify which fields they want to be returned, why is it still necessary to have GET /observations/{uuid}, if some of those extra fields could be added to the GET /observations response instead?
right now, if you don’t need to get non-traditional project information, you wouldn’t need to use GET /observations/{uuid} at all, but if you do need that information, you might have to do a query to GET /observations to utilize its more robust parameters and then do additional requests on GET /observations/{uuid} to get the additional information. it seems inefficient, considering you can now specify only the fields you need in v2.