Period columns are used to support the temporality of data and have no business logic value. By using the HIDDEN clause, you can hide the new PERIOD columns to avoid impacting on existing applications that are not designed to handle new columns. The following code will create two temporal tables, one with default values (visible period column) and the other with hidden period columns:

CREATE TABLE dbo.T1( 
   Id INT NOT NULL CONSTRAINT PK_T1 PRIMARY KEY, 
   Col1 INT NOT NULL, 
   ValidFrom DATETIME2 GENERATED ALWAYS AS ROW START NOT NULL, 
   ValidTo DATETIME2 GENERATED ALWAYS AS ROW END NOT NULL, 
   PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo) 
) 
WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.T1_Hist)); 
GO
INSERT INTO dbo.T1(Id, Col1) VALUES(1, 1);
GO
CREATE TABLE dbo.T2( 
   Id INT NOT NULL CONSTRAINT PK_T2 PRIMARY KEY, 
   Col1 INT NOT NULL, 
   ValidFrom DATETIME2 GENERATED ALWAYS AS ROW START HIDDEN NOT NULL, 
   ValidTo DATETIME2 GENERATED ALWAYS AS ROW END HIDDEN NOT NULL, 
   PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo) 
) 
WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.T2_Hist)); 
GO
INSERT INTO dbo.T2(Id, Col1) VALUES(1, 1);
GO

When you query both tables, you can see that period columns are not listed for the second table:

SELECT * FROM dbo.T1; 
SELECT * FROM dbo.T2;

Here is the result:

Id   Col1        ValidFrom                   ValidTo
--- ------ ---------------------------   ---------------------------
1    1      2017-12-14 23:05:44.2068702  9999-12-31 23:59:59.9999999


Id          Col1
-------- -----------
1           1

As you can see, period columns are not shown, even when you use * in your queries. So, you can implement temporal functionality for a table transparently and you can be sure that your existing code will still work. Of course, if you explicitly specify period columns with their names, they will be shown in the result set.

Hidden attributes let you convert normal tables to temporal tables without worrying about breaking changes in your applications.