The problem with knowing the object_index (or any other resource's index) is that's only going to do you any good in a final build. As soon as you make any changes to the resource tree, you risk breaking the program if you base anything explicitly on the resource indices. Saving object_index to an INI file, for example, is a case where your code is based explicitly on a resource index. If the first time the program is run it writes 32 for an object_index, you could load the INI file, fetch that object_index, and recreate an instance of that same object in the room. However, if in your next build you patched it so that a new object was added to the resource tree, when that INI file is loaded, it might create an instance of the wrong object.
Now, you can code around resource indices indirectly just fine as long as you avoid using an explicit basis. For example,
sprite_index = spr_cat_bw + breed;
In this example, spr_cat_bw is the first sprite in a series of sprites and breed is a value from 0 to whatever. Each of the sprites are in order with no other sprites between them. As long as breed is not negative and as long as breed is not larger than the number of sprites in the series, then the sprite_index will be fine. However, this should only be used in a final build or in a program that has no save features which incorporate the breed. If the user could save the value of breed, then you would have an explicit basis and changing the order of sprites in the series around would result in a different sprite being shown for the breed that was saved. It should be noted that "final build" in this case merely refers to the series of sprites; you could patch the hell out of the project without affecting what sprite gets shown as long as you don't change the order of the sprites in the series.
When running little tests where I decide it's better to just toggle between rooms, I indirectly refer to the room IDs.
room_goto(room ^ 1);
That will let me jump between the same two rooms to my heart's content with just that one line.
But in all of these cases, you don't actually ever know the NUMBER behind the resources. That's the nice thing about Game Maker -- you pretty much never need to know the actual numbers. Every resource has its number assigned to a constant -- the resource name. So in most cases, you just need to know the resource's name. In the case of the codes I gave, you also just need to know the relationships between the resources (e.g., which sprite comes first, how far apart the sprites are).
object_index = obj_fatcat + global.breed;
show_debug_message(object_get_name(object_index));
GM needs to know the number, but you don't.