Until the authors reply, you might find some of the answers in this discussion.
1. Spatial databases *are* normal RDBMS, but with additional data types and functionality.
Spatial data tends to come with a lot of scalar (non-spatial) attributes e.g. a table listing hospitals might include the location (spatial data) but also the name, street address, phone number, size etc. So if you include a spatial data column on a particular table, it becomes a spatial data table and you can apply various spatial functions to the spatial elements of the data e.g. find the nearest hospital to your current location.
If there are no spatial data columns, then it's just a regular table. In both cases, you can still do all the usual SQL stuff on the non-spatial elements in the data. And of course you can combine spatial and non-spatial operations, which is one of the many benefits of using a spatial database.
2. Spatial databases offer all the usual benefits of a database, plus support for spatial storage and processing.
Many smaller/medium sized GIS applications still use a file based approach (usually ESRI's shape-file format or its more recent proprietary "geodatabase" format), which some people regard as being more flexible. But it's a bit like using spreadsheets instead of database tables - there are strong arguments for maintaining a "single source of truth" in a robust, flexible and maintainable database, especially if you have large volumes of data.
Some people extract subsets of spatial data from a spatial DB into shape-files etc and use these for particular purposes such as creating specific maps (just as people may extract normal data from the DB into CSV files for reporting etc), but continue to maintain the source data in the database.
Depends what you want to do, but the spatial database gives you a lot of built-in power and flexibility.
3. I'm no expert on spatial DB architecture, but you'd certainly need to take account of things like spatial data volumes and indexing, choices over whether to edit spatial features in the DB, preferred storage and I/O formats (e.g. SRS, XML services, shape files etc), compatibility between different datasets e.g. long/lat data and national grid references, and possibly issues such as storing spatial features at different resolutions for display at different scales. Again, it all depends what you want to do with your spatial data.
4. Oracle Spatial is an add-on to the standard Oracle RDBMS and has been around for many years. Other RDBMS have started to add spatial support more recently, but AFAIK Oracle and PostGIS/PostgreSQL are probably the most mature and comprehensive examples of spatial databases.
Historically, GIS specialist company ESRI has provided a heavy-duty middleware server to add spatial functionality (and support for other ESRI GIS tools) to SQLServer databases among others. Not sure where this is going these days, but it used to be very expensive and is definitely aimed at specialist GIS applications. I suspect that ESRI's close association with SQLServer might actually have been a factor in delaying the arrival of spatial support on that DB platform.
There are regular debates in the GIS world over the benefits of using highly functional but closed and proprietary middleware approach like ESRI, versus using a more open spatial database plus a mix of open source or proprietary GIS tools that can interface to a spatial database. Depends what you want to do and how much money you have!
5. Check some of the other threads in this forum for comments on spatial ORMs. JDBC etc works as usual for the non-spatial aspects of spatial databases, and you may also be able to encapsulate a lot of spatial processing behind interfaces to stored code e.g. PL/SQL (Oracle) or PGPLSQL (PostgreSQL) packages within the RDBMS.
Another approach is to use XML-based web services such as WMS and WFS e.g. in combination with the excellent open source GeoServer and appropriate client-side software which can range from high-end client-side tools for GIS mapping to lightweight browser-based interfaces using open source AJAX libraries such as OpenLayers.
Hope this helps.
No more Blub for me, thank you, Vicar.
They weren't very bright, but they were very, very big. Ad contrast:
Free, earth friendly heat - from the CodeRanch trailboss