You’re not losing anything by using “current user” - it’s another way of identifying the current user through a “built-in shortcut” as @philip described. The url parameter route and the “shortcut” route are just two different methods with different advantages and efficiencies. Identifying the current user is much, much easier via “current user” since you don’t need to search for it.
To find the current user (or any user whose Id is in the url parameter for that matter), your expression would be “do a search for user: first item, constraint: unique ID= get data from URL (where parameter=ID)”. So to retrieve the current user’s name, for example, you’d have to go through all of that search trouble to create “do a search for user: first item’s name” when you could just do “current user’s name.”
Examples of where the url parameter is useful: sending data that might not be stored in your database Iike a form response that needs to be carried to the next page but not saved yet, a referral code shared outside the app, or states unique to the current user’s experience like taking the user directly to an FAQ question from another page (e.g. They click a reference to the FAQ, passes a parameter to indicate it, and when on the page, it scrolls directly to it).
If the page in question is set to a data type, then you’ll more often than not be able to send the data of a specific Thing when navigating to the page directly in that workflow and do nothing more. Then, when on the page, you’ll have access to the “shortcut” of “current page’s Thing” and all its fields for the specific Thing the page is reading.
Hope this helps.
Gaby | Coaching Bubble