is a handy utility.
First, when we append a geometry column to an existing table with
SELECT AddGeometryColumn('my_table', 'geo_column', 1234, 'MULTIPOINT', 2);
we're feeding the function everything it needs to tack the column of type geometry (geo_column) to the specified table (my_table) and write the important details like SRID (1234), geometry type (MULTIPOINT) and number of dimensions (2) to the geometry_columns table. In essence, it is an ALTER and three UPDATES.
Creating geometry columns by other means (loaded from shapefile, selected in a CREATE TABLE AS, etc.) can lead to spatial tables that are invisible to external applications, although they work just fine within the database. Without the right details stored in geometry_columns, the actual geometry values appear as nonsensical character strings to applications looking for projected points, lines or polygons.
Calling the probe function checks each column of type geometry, adding new values to geometry_columns and reporting conflicts.
Circling back to your question, GeoServer doesn't believe the renamed table contains spatial data if the name change isn't reflected in geometry_columns. Something else to consider is that the probe function creates a duplicate record reflecting the new table name but does not get rid of the original record--another potential hang-up for GeoServer.
All that said, I would suggest you: 1) run the probe then immediately delete the old record; or 2) follow up your name change with an ALTER on geometry_columns to change the f_table_name value.
Sorry for the wordiness, but I hope it helps.