1. yes go for LMT
2. RMAN is my choice.
   if you have more space, take an export.
3. failover ? u mean application failoover or hardware failover?
   depending on how much u want to spend $$ u can go for. 
   ORACLE RAC is ideal choice.
4. did u get a chance to look into workspacen management?
5. Cloning or DUPLICATION is more powerful using RMAN.
   we have automated this procss to happen every week.

for workspace management please have a look [url= http://www.orafaq.net/cgi-bin/search/highlight?q=workspace%20thiru&url=http://www.orafaq.net/msgboard/server/messages/21211.htm] here [/url]

indexfile option has nothing to do with this.
if specified indexfile=somefile.sql , the ddl of the tables and indexes in the dump file is extrcated and written to the file . thats it.

export from 805 to 9i will work.
how to  make sure, the tables and objects are in right places?

precreate the tablespaces for data and indx in target db ( like the same in source..if not possible to have the same name NO problem).
create the user.
grant user quotas only on these two tablespaes.
run the import .
check the obnjects manually ( whether they exist in right places).
sometimes,if there is a primary key in table,
the index might be created in the data tablespace itself instead of index tablespace.
You may move those indexes later to appropriate tablespace.

a simple script might show u where the tables and indexes are created...

dbadmin@republic_lawp1 > @tb_lawp

TABLES and INDEXEs owned by LAWP_LAWSON

TABLESPACE_NAME     tables
--------------- ----------
DATA                  1825

TABLESPACE_NAME    indexes
--------------- ----------
INDX                  5212

dbadmin@republic_lawp1 > get tb_lawp
  1  column tablespace_name format a15
  2  prompt
  3  prompt TABLES and INDEXEs owned by LAWP_LAWSON
  4  select tablespace_name,count(*) "tables" from dba_tables
  5  where owner=upper('lawson')
  6  group by tablespace_name;
  7  select tablespace_name,count(*) "indexes" from dba_indexes
  8  where owner=upper('lawson')
  9* group by tablespace_name;
 10

u can avaoid that
case: export objetcts by scott and import into to another schema in another database
source_db
       username=scott
       pasword=tiger
       default tablespace= scott_data
       and indexes are in = scott_index
target_db
       username=magellan
       pasword= something
       default tablespace= magellan_data
       and indexes are in = magellan_indx

now during import do the import schema by shema

import dba/pass@target_db file=somefile.dmp fromuser=scott touser=magellan 

----------------------------------------------------------------------

all the tables in scott_data will be created in magellan_data ( becuase magellan_data is default tablespace for magellan)
if there are tables in other tablespcaes, they also will be created in magellan_data ( since it is defualt.  IF u have give resource role, then it will be created in the tablespace_with_same_name as in source. But since u have quota only in those two tablepsaces u can avoid it)
all the pk indexes are also created in magellan_data.
later we can move them to whereever we want.
using the script, if the tables are scattered everywhere, we can move them later.

 

by default, tablespace is LMT in oracle 9i.
so unless u specificly create  an DMT, u will not be having an dictionary managed one.
with export/ import u deal ( ie export or import ) only data and objects.
exp/imp tools will not see this as migration.
if the target db has an LMT it will dump data there.
the issues when moving data from dictionary manageed to local managed arises when u go through the 'migration' path using DBMA /ODMA or running manual scripts ( in that case, first u should upgrade to 8.0.6 and then to 9i. 8.0.5 is desupported by oracle)
As per ur first posting 
"Since this is a small app, I guess they did not care as long as "

the database is not complicated ( likewith oracle text/ spatial etc).
considering this.
install new 9i binaries. ( dont create the seed database).
createa customized database
create users and tablespaces ( like the source)
export source and import into target.
this works good ( as long as the db is not complicated. we have completely automated this 'process' of moving data from one our legacy databases (8.0.5 HP-UX) to (9i RAC,sun ) through export/import.)

it just a straight forward export import process.
1. first export the source ( from source machine ..oracle 805 server.. i export with out indexes)
2. drop the existing tables in target ( an sql script)
3. import to target ( run the import for source . always use lower version of exp/imp executables to do export and import when there is a difference in the version of oracle. else u need to install the views in the lower version of oracle)
4. rebuild the indexes ( i have a seperate script that extracts the ddl of the indexes from the source)