If your application is going to go into database replication you will need to use a guid (globally unique identifier) instead of a sequence for your primary key. This will allow replication of your table to databases at other locations. In general I think replication is pretty much inevitable for all robust applications and we should start using quids instead of sequences everywhere. I havn't used them enough to evaluate their impact on performance in high transaction environments.
I would never generate primary key values in code. If you do, your table is linked to your code segment because you can't do inserts without it. This makes it much harder to move the database to a new platform or to write other applications that use the same table.
Here is a clip from the Oracle documentation:
SYS_GUID generates and returns a globally unique identifier (RAW value) made up of 16 bytes. On most platforms, the generated identifier consists of a host identifier and a process or thread identifier of the process or thread invoking the function, and a nonrepeating value (sequence of bytes) for that process or thread.
Example
The following examples return the 32-character hexadecimal representation of the 16-byte raw value of the global unique identifier:
CREATE TABLE mytable (col1 VARCHAR2(10), col2 RAW(32));
INSERT INTO mytable VALUES ('BOB', SYS_GUID());
SELECT * FROM mytable;
COL1 COL2
---------- --------------------------------------------------
BOB 5901B85D996C570CE03400400B40DCB1
SELECT SYS_GUID() FROM DUAL;
SYS_GUID()
--------------------------------
5901B85D996D570CE03400400B40DCB1