It didn't seem like people were really addressing the second part of your question so I thought I'd chime in.
First, I like both answers to part 1 of your question. I think either a materialized view or creating a stored procedure to manage inserting into the second table are satisfactory (+1'd both of them). I like the flexibility of using a stored procedure better, however and believe using packages/procedures for your CRUD operations to be how most interaction with database structures should be handled. Your instinct to move away from Triggers is a good one, in other words - they have their uses but I think they tend to obscure business logic by placing it outside the direct method call stack (if you didn't know the trigger was there, you might not realize where its functions are coming from).
That being said, I move on to the second part of your question - "What would I loose in the real world app be replacing an Insert trigger?"
If you replace your trigger with a CRUD package and you don't control all of the input paths for inserting into your database such that they all use that CRUD package, you cannot guarantee that the logic previously embedded within your insert trigger will be activated on inserts.
Alternatively, if your trigger logic is simple enough to be replaced with a materialized view that was set to update on commit, you wouldn't have the problem outlined above, and would likely see no difference at all.