Custom Table Guide: What is this?!

The other day I was looking at the licensing training and thinking about the custom table guide.
To me it's very bizarre why these are the tables selected so in this post I want to talk through each of them.
If you have any thoughts to the reasoning I'd love to have some back and forth on it. Here's my thoughts so far.

Table	Label	Reason	Extensible OOTB
`cmdb_*`	Configuration Items	Design Choice - has a Class field and it's in use	Many No
`cmn_location`	Location	See notes below	No
`cmn_schedule_condition` new			Yes
`dl_definition`	Data Lookup Definition	Design Choice - has a Class field and it's not used	Yes
`dl_matcher`	Data Lookup Matcher Rules	Design Choice - has a Class field and it's in use	Yes
`kb_knowlege`	Knowledge		No
`sc_cat_item_delivery_task`	Exection Plan Task []	Design Choice - has a Class field and it's in use	Yes
`scheduled_data_import` new			Yes
`sf_state_flow`	State Flow	Design Choice - has a Class field and it's not used	Yes
`sys_auth_profile`	Authentication Profile	Design Choice - has a Class field and it's not used	Yes
`sys_choice`	Choice	I cannot find a reason this is included	No
`sys_dictionary`	Dictionary	Design Choice - has a Class field and it's in use	Yes
`sys_filter`	Filter	Design Choice - has a Class field and it's in use	Yes
`sys_hub_action_type_base`	Action Type Base	Design Choice - has a Class field and it's in use	Yes
`sys_import_set_row`	Import Set Row	Design Choice - has a Class field and it's in use	Yes
`sys_portal_page`	Portal Page	Design Choice - has a Class field and it's not used	No
`sys_report_import_table_parent`	Report Import Table	What does this table even do?	No
`sys_transform_map`	Transform Map	I cannot find a reason this is included	No
`sys_transform_script`	Transform Map Script	I cannot find a reason this is included	No
`sys_user_preference`	User Preference	I cannot find a reason this is included	No
`sysauto`	Scheduled Job	Design Choice - has a Class field and it's in use	Yes
`syslog`	System Log	I cannot find a reason this is included	Yes

My thoughts on extending tables

I can categorize my opinions about when and why to extend a table into three reasons.

Edit: At the time I wrote this, there were two things I had not considered. One. Extending tables is really complicated.

Pros	Cons
You get all the fields from the parent	You get all the fields from the parent
	You could add fields that may hit the limit of the technical length in SQL
	Reporting on it can be difficult
	If you need two records with the same unique value in the two tables, the system will not allow this
	To extend some of these tables is uncharted waters and may not work well see sys_choice

Usability

Assuming you have a table in mind;
Does it make sense to have/modify a "type" or "class" field and have one the table?
Also, does the new type inherently change the the record that it is very different?

If yes to both, extend, if not make new.

Scoped Access

Sometimes you cannot create or read records that you might want to use in a scoped app, see sys_user_group.
In this case it may make sense to extend that table if you want to create/modify those records. This is a
technical reason, and I feel they likely should not be extended still but must be.

Design Choice

Generally, something will automatically extend a table, like Import Set Row.
Anytime you upload a new file as a data source that is extended.

This is done by adding a class field to indicate the class of record.
Some records with this only ever have one class, like sys_auth_profile.
Some have many like cmdb_ci, sys_user, and task.

Configuration items

Sometimes you gotta extend this to track things your work considers as a CI but ServiceNow has not. E.g. Rooms

In the example of Rooms, out-of-box there is a "Computer Room" CI class, but you may want to track conference rooms,
data closets, supply rooms, etc. In these cases in my opinion extending cmdb_ci makes sense.

Knowledge

Knowledge is an interesting table to have here.
On one hand you could argue some Knowledge articles should be typed/classd differently.
I believe Knowledge already has this.

#ServiceNowDev #blog What is with the Custom Table Guide https://t.co/b2Gecq8WOW
— Jace Benson 👨‍💻⚙️ (@jacebenson) November 27, 2019

Further Reading: https://docs.servicenow.com/bundle/newyork-servicenow-platform/page/product/knowledge-management/concept/knowledge-article-templates.html

Location

Location is an odd table to me to have on this list.

I'm trying to imagine a situation where you might have different location types, e.g. Offices, Kiosks, and Datacenters

In these cases I can't imagine a situation you would need this extended. Now scoped apps cannot write to some common tables,
if that is the reason this is here that may make sense. If a scoped app needs a place to write to that is like location, but different
extend it and write to the extension. If that is the case though then I'd expect the same for Group Memberships

With all that being said, on initial look of the table, it does not sport a sys_class_name field.
However it also has "Extensible" as false.
If you change "Extensible" to true, then BOOM, now there's a sys_class_name field.
I'm still not sure I agree with the all the ideas of this.
That being said it seems like a Design Descision now. - Jace 2019-12-16