No. Temporal tables are not a replacement for event sourcing. They are complementary technologies. Temporal tables simply make a copy of the data to another table before updating or deleting the current state. The temporal table includes time stamps so you can query with
AS OF and other new temporal keywords. If you issue a normal query, you will only get the current state as though it were not a temporal table.
Event sourcing can be thought as a transaction log or a queue of deltas. The events must be translated into a model (e.g. object or table) before they are useful.
A temporal table would be more appropriate for keeping a change history on CRUD data. Such data often has set constraints like uniqueness that a relational table can address, but an event store cannot. For instance, a Product configuration (ID, SKU, names, price, keywords, ...) could be an appropriate entity to represent in a temporal table and be able to track over time.
Event sourcing is more appropriate for permanently recording facts that multiple observers may be interested in. The ordering process could be an appropriate thing to store as events. This generally has a defined beginning (order placed) and end (order delivered or canceled) and several things that happen in between (payment received, payment rejected, order shipped, etc). And several different groups want to know about these events to coordinate work: Fulfillment needs pick lists to pull the items from warehouse, Shipping needs weights and dimensions and packing lists to arrange trucks, Sales Support needs contact info for orders with problems, Marketing wants to know trends, etc. Each of these groups has their own goals for the data. So having a one-size-fits-all data model (one Order table to rule them all) often does not work. Instead each group can read the events and apply them to their own purpose-built model. A temporal table does not help to accomplish this scenario.