I am working on a codebase which has the following type of pattern for generating surrogate key for tables.
create or replace
TRIGGER TEST_TRIG
BEFORE INSERT OR
Trigger and insert statement both have different functionalists if you want just to insert the data and put no logs for that insertion than this insert Statement would be fine but that you can be sure of integrity of the data in table as it can be modified by a number of sources on the other hand if you want logs for every insert/update statement fired on the table irrespective of the call in your block triggers would be helpful and data integrity can be given a check at any point of time.
This particular pattern is actually quite dangerous as it allows someone to manually input a new ID that might clash with an already extant surrogate key or one that your sequence might generate in the future.
Your trigger should really look like this to ensure that for every new record gets a unique key. If you're using 11.2 or higher there's no need for the select ... into ...
CREATE OR REPLACE TRIGGER TEST_TRIG
BEFORE INSERT ON my_table
FOR EACH ROW
BEGIN
:new.column1 := my_table_seq.NEXTVAL;
END;
The benefit of this approach is that it's always done. Whatever value anyone puts in for this column gets overwritten to something that will work and which uses the correct sequence; if someone forgets to add it in the statement will still work.
It makes it impossible to break your surrogate key.
With what you suggest, imagine that someone places a 1 instead; you get a primary key violation. If someone forgets then there's more errors. You'll never guarantee that every update to your table will be through a single point of entry so the trigger guarantees that the PK is populated correctly.
It's worth noting that from 12c you can use an identity column, which makes explicit the link between table and auto-increment; there's no need for a trigger or a sequence. The syntax for the table creation DDL would be:
create table <table_name> ( <column_name> generated as identity );