While I agree that the creation of "history" and other forms of "audit" tables do, in fact, use extra disk space, if you need such a thing, it's a tough fact to avoid. Column-Store indexes can help there but you do have to be careful there with performance and you do have to remember that Temporal Tables are page-compressed by default. I've not looked it up but I don't know if you can actually have column-store indexes in the presence of compression. You may have to override the default.
One of the things that does bug me is that you can't relegate the history table to a different database and have it operate by synonym. The reasons why you may want to do such a thing is to set the different database up as (possibly) a different recovery model than the original database and also move things like large "history/audit" tables out of the original database to make rapid DR restores a possibility to "get back in business" more quickly.
I've also not yet tried to capture the name of the Session User in the "history/audit" table as a default so that you don't have to have code do it possibly incorrectly or be missed altogether. That'll be an experiment that I do in the very near future because I actually have a pressing need to do so.
To Harish's point, there can be a huge amount of unwanted wasted space used if the table has a huge number of columns and the normal column count of updates is very small (say, a 150 column wide table where, after the first insert, only 4 columns are usually updated). The same holds true if the table contains LOBs (the article that uberbloke cites, mentions that particular issue) or suffers from a lot of "out-of-row" activity from large numbers of overly large variable width columns.
Other than those things, I see Temporal Tables as being a MUCH better and faster solution than home-grown solutions, especially when the end result is to have the ability to determine a "point-in-time" state for any of the rows in a table. In other words, MS (IMHO) did a great job in instilling Type 6 SCDs (Slowly Changing Dimensions) in Temporal Tables both for writing to the "history/audit" table and reading from the primary table and the "history/audit" table by date/time.