Do not rely on object_id for your application.
My experience is that once an object is created its object_id will be stable for as long as that object exists. The difficulty is in knowing the meaning of "as long as it exists."
If the object is dropped and re-created it will get a new object_id, even if the exact same statement is used both times, creating an object with the same name.
If the creation script runs against different databases (say DEV and TEST) it will generate different object_ids.
If the database is restored old object_id values may re-appear.
Most risky is that stability of object_ids is not documented and therefore is not guaranteed. A patch, upgrade, security patch or anything else may change IDs for existing objects if MS determines this is something they want to do for any reason whatsoever at all.
MS can use object_id in their internal metadata because they know all the places that can invalidate these values and can write their code accordingly. They do not publish these details for us, as application programmers, to consider.
If you need to reference objects in a data-driven way, store their names. Use the correct datatype (SYSNAME) and don't forget to store the object's schema, too. If a numeric value must be passed around there are some options. An identity column could be added. Values will be different between environments and when objects are removed and re-added. Really this is no better than object_id. Better may be to calculate a hash of the schema and object names. If the hash algorithm used is communicated broadly every consumer should be able to generate it on demand. If you have authority over the objects' names (which seems likely since you're writing them) you could simply choose the corresponding ids and publish them. Don't forget the unique constraint on the name and id columns!