Oracle 8i was desupported at the end of 2004. This includes both the 32-bit and 64-bit versions. (I just queried MetaLink to double check.) Isn't that enough of a reason to upgrade to something?
But, why 9i? Oracle shifted its internal resources away from 9i to 10g last year. They are slow to fix things in 9i because the developers were moved to 10g. Nothing new goes into 9i, and some bug fixes might not be implemented in 9i. Based on those support issues, why not 10g? It's a stable development platform, and 10g Release 2 will be out this summer. If I were starting a new project today, or starting an upgrade plan, I would focus on 10g.
In terms of some specific differences between 8i and 9i,
1. 8i runs faster than 9i, from my experiences. I moved a lot of databases from 8i to 9i over the past two years, and a well tuned 9i database runs slightly slower than a well tuned 8i database. 10g is faster than 8i and 9i.
2. 9i was Oracle's first release to support ANSI standard SQL. Maybe that's important to your office, maybe it is not.
3. UNDO is way better than RBS.
4. 9iR2 added automatic segment space management, so you no longer need to worry about free lists and stuff like that.
5. There were a lot of problems with 8i that I did not see in 9i. Like the TEMP tablespace getting hosed. There's tones of web postings about TEMP not releasing space in 8i without bouncing the database, but if you use 9i's CREATE TEMPORARY TABLESPACE syntax it does not occur.
6. Some offices like the SPFILE better than the init.ora file. Mostly it is better for RAC users, but some benefits to non-RAC users too. I don't use SPFILEs in development, but it's great in a test/prod environment. When you study up on the new 10g features there are additional reasons to use the SPFILE.
That's just off the top of my head. If you buy the 9i OCP study guides you should get a much better feel for the differences. Also, checkout the 9i on-line documentation. Each book has a chapter called "What's New."
As a PL/SQL developer there's no comparison. How did we manage without analytics and CASE statements in procedures, or MERGE and multi-table INSERTs, or the funky KEEP clause for GROUP BY?
Associative arrays ought to be useful, but I can do so much more in SQL now, I barely use them.
The new TIMESTAMP and INTERVAL types give a lot more flexibility than the old DATEs (and you can now write your own aggregate functions, which could be handy since Oracle neglected to override AVG and SUM for intervals).
The enhancements to object types mean they are starting to be useful, and some of the syntax is simplified too, since less explicit casting is required.
External Tables reduce your reliance on OS scripts calling SQL*Loader, and Pipelined Functions give you a new way to approach data transformations, since you can essentially have procedural views.
Also back on the DBA side, you can now use locally managed tablespaces for SYSTEM and temp, which means the old dictionary-managed tablespaces are history.