Currently a table does not support the usage of HiddenFields or fields that are visible to the user but that can’t be edited.
Use case
I want users to be able to batch edit names of uploaded gefs since often they come in quite unpleasant names such as CPT000000072790_IMBRO_A.gef or 1318-0211-000 HB07 (HB10-16_2+150D) (NAP) VELD.gef. In order to do this I have built a table with 2 columns, the current entity name and the new one. With a button the current names are filled out, the user can enter new names and with another button “save the changes” which renames each gef entity to the new name.
In order to rename the gef entities I need their entity_ID since using the entity_names is not ideal since these are not always unique but the ID is. To the user however the entity_ID is a confusing number/parameter and therefore I don’t want to show it. My current workaround is that when pressing the button to fill the tabel with the current gef entity names, a dictionary of entity_name to entity_ID is stored in the persistent storage. This creates a sort of shadow copy of the table though and can cause problems when a user mistakenly edits the current entity name column in the table. A solution for this problem is to either allow HiddenFields in a table (in that case the entity_ID can be a hidden 3rd column), or allow the usage of fields that are visible to the user but can’t be edited (so that the user can’t edit the current entity name).
Why not use a Dynamic Array?
The problem with using a Dynamic Array is that it takes up much much more space in the interface since for each field the name of the field is shown in each “row” whereas a Table presents this information efficiently.
Why not include the entity_ID as a visible column and place a warning to the user that they shouldn’t edit the column
The entity_ID is often a difficult concept for users to grasp. Next to this, it is unnecessary information to the user since for them the entity_name is sufficient. Placing a warning to not edit the column of course helps but does not completely stop the user of editing it anyways (unless you have perfect users in which case let me know your secret 
)
Why not use the entity_name instead of the entity_ID
In the past we have used this but the entity_name is not 100% guaranteed to be unique. It does not occur often that multiple entities have the same name but in the off chance that it does it can create a lot of problems. The entity_ID is always unique and therefore much more preferred to retrieve entities with.