Mostly it's the technology that is the big difference... using an SDK installed in the app, with greater reliance on the developers... while yes this can be connected to Launch, you can't run JS or do a lot of manipulation of the data, there is no DOM to read, etc...
For your specific questions:
1. What is the correct terminology that is used for each page in Mobile app. Is it a "view", is it a "page"? What is the standard way of defining it?
Meh, some systems call it a "Screen View"... but really, we just continue with the "Page View" terminology... especially since in Adobe, you will use the page view metric. We roll all our apps into the same global suite as our websites... we pass the same "page names", "channels", "URLs" (even though it's a native app, each page or screen of the app has an equivalent web URL, so we pass that), all the same dimensions and metrics, etc...
We have a few "lookup" type dimensions, such as our "breakpoint" which on web tracks desktop, tablet or mobile depending on the responsive breakpoint, and on our apps we send app|mobile or app|tablet depending on if it's the phone or tablet version. We also have another dimension which is used to help distinguish all our variations, "core site", "obituaries", "classifieds", "app", etc (basically this allows us to segment by the the site or app we control, or our third-party subdomains, etc).
There are a few app specific features that have tracking that doesn't exist on our web, and we just note that in the description of the dimensions and metrics used for them.
2. Are there URL's in mobile apps? If so how do they work?
I touched on this briefly... if you have a Native App, then technically no... if you are using an app wrapper and webviews (definitely yes, but you also have to make sure you aren't double counting your app and web on the same view). However, as I mentioned, we know exactly what pages belong to what URLs, this is also part of the Universal Linking (i.e. if someone opens a link on their phone, and they have the app installed; the app will open to that page and not open in a browser). I am sure you have seen this behaviour in other apps. So while the page itself is not really loaded via a URL, your developers should know the equivalent URL that they can pass for tracking purposes.
3. Is it recommended to track URLs / URIs in mobile apps in regards to performance tracking and marketing analytics?
I would say absolutely yes... this also falls in line with our Universal Linking... for us, when a user opens a newsletter or marketing email link for instance, there are campaigns... I track the URL (with those campaigns), which also will get picked up by my Marketing Channel rules, but I also make sure my developers get all my campaign data so I can pass it to the standard Tracking Code dimension (1 week attribution), as well as all my custom campaign tracking solutions (which are all set to Visit level attribution).
And while I have a lot of URLs, so that the low traffic bucket applies, for popular pages, I can segment or pull data based on URL across my network (web and app together) because I am tracking the URL.