First, the unique attribute only applies to custom fields, and is always configured by an administrator, usually to enforce unique values and improve database performance. No system fields that I'm aware of have the unique attribute set, even the Id field, even though "normal" objects, like Account, Contact, and even ApexPage, will always have a unique Id. Some read-only back-end objects may have an Id of a value set to a related record, or no value at all, and most probably won't be unique. I don't have a list of which objects act like that, but I've encountered one before.
Next, the ApexPageInfo object appears to be a housekeeping object for the underlying metadata of a page, such as its API version, Description, and Label. Typically, this means that you need to use the appropriate channels, such as the Tooling API or Metadata API, to modify the contents of this object; the object itself appears to be read-only (no create, update, or delete operations are allowed). This is indicated by the fact that the Id values that are queried seem to be 000000000000000AAA, which is the "empty Id" value, a blank placeholder used in place of null within the database for Id-type fields (lookups, etc).
The object itself has a key prefix of 4ve, which does not respond to the usual tricks we'd use to look at the object (e.g. instance.salesforce.com/4ve/e responds with "URL No Longer Exists" instead of the more telling "Data Not Available" error). It's possible that internally, these objects have a 4ve Id, and the database engine simply "masks" them for us, which also suggests that we're not meant to play around with these records for whatever reason. I suspect that if we could modify them, we'd find that we're allowed to do things we shouldn't be doing to them, like creating more than one entry per page, or deleting an entry and crashing the page when it recompiles, etc.
So, it's great if you want some read-only data of your pages, like finding out which pages are not running on the latest API version, but that's pretty much all it's good for. Also, this object doesn't appear to be in any of the standard documentation, so it's probably not even meant to be used, although we do have the ability to query it, which is kind of unusual for an object with no Id. Unless you have need of this data in some specific way, I'd consider just ignoring it.