All records that you can view in the UI should have an Id, because that's how they're displayed and referenced in the database. There are actually a small handful of objects that either do not have an Id (you can query the field but all values will be null), do not have a unique Id (e.g. the Id field will contain duplicates), or do not have an Id field you can query.
Generally speaking, if you can find the object in the Salesforce documentation, it will have an Id field that is non-null and unique. I have a nagging memory I can't quite place that there may be one or two objects that are documented that don't have an Id, but I can't seem to find them at the moment; virtually every object you use on a daily basis has an Id. The Salesforce WSDL "guarantees" that sObject types have an Id, as the base sObject type in the WSDL has Id defined.
Other objects that we can discover through describe calls, key prefix scanning, etc, may or may not have an Id field, or have non-unique Id values. One such object is the ApexPageInfo object, which is undocumented, may be queried and described, and all records we query have the null Id 000000000000000AAA.
I have occasionally run across other objects that exhibit odd behavior, like refusing to be described, having literally no fields, or other oddities. However, as long as you're limiting yourself to objects that appear in Schema.getGlobalDescribe(), the records should have an Id field that is visible, queryable, not-null, and unique.
If you allow the user to type in any random string instead, a user might stumble across an object that is outside the documentation, and thus subject to unusual behavior.