I’m not from Companies House, just another forum poster, but:
a) The design of the API seems to be more in terms of “links” and “following links” rather than being focussed on “obtain / provide IDs”. Furthermore it seems that Companies House actually maintains several data sets and (at least as far as the ID exposes) the IDs and data do not necessarily map between these (e.g. disqualified office ID has nothing to do with officer ID in the Public Data Office Appointments). Outside of the Company number I would just treat these with caution - perhaps relying primarily on your own generated ID to refer to any entities you store / process data for.
That being said I’m not aware these do change - but note there are some data/process issues * with this dataset. (Aside from those inherent in Companies House legal responsibilities as a recorder, and this being a large, long-lived public dataset.) See e.g. multiple entries for “the same” individual as a PSC etc. (you can search this forum for any other issues).
b) Many (all?) of the endpoints in the Public Data API and Document API return a links member which has a self reference. Like everything in the API (and remote APIs in general) I would not assume it will be there. In my experience it’s always sensible to parse returned data - and have some system for handling missing / unexpected responses e.g. error logging / reporting. And ideally one which can skip data that you don’t actually rely on (for many uses you won’t need the “self” link I would imagine).