I'd imagine that having your data split across multiple tablespaces (and therefore potentially multiple disks) would improve the seek times.
Your whole premise behind the question is faulty. You do not need to split your data between tablespaces to spread the i/o across more disks, you need to increase the number of disks in your RAID10 or (better still) ASM array. You will get less performance gain, less space efficiency and far more maintenance trying to manually tune the i/o like you are suggesting.
ASM beats RAID10 primarily because it understands the data being written to it - so for example it can vary the stripe size between data blocks and logs.
Shared nothing typically refers to hardware, though it could also be used when describing an SOA architecture.
From a hardware perspective, a "shared nothing" Oracle database simply means a machine using local disks, memory, etc.
Oracle RAC (real application clusters) is a shared disk architecture, but not shared memory. Horizontal scaling is then achieved by adding more machines to the cluster.
When talking in SOA terms, "shared nothing" means that each service has a corresponding database which is only accessed by that service. So the ACCOUNTS service accesses the ACCOUNTS_DB, ORDERS service the ORDERS_DB and so on. These databases could be shared nothing from a hardware perspective as well, or use RAC.
Ensuring consistency of data and references which would normally be handled using foreign keys becomes a challenge in SOA shared nothing databases.
Sharding typically refers to partitioning managed at the application level, rather than within the database. For example, you could partition accounts by email address and direct customers with address starting A-C to ACCOUNTS_DB01, D-F ACCOUNT_DB02 and so on. The shard mapping could be a simple range like this, a function on the input or a lookup database stating which database is stored in. The databases would be "hardware shared nothing" in this case as the idea is you use relatively cheap machines which are easily added and replaced.
You could shard your databases at the application level and still have Oracle partitioning at the table level within the database itself. So you could shard your ORDERS database by customer, then partition the orders table by order date as well inside the database.
The downside to both meanings of shared nothing comes if you frequently run queries that have to access several databases. In these cases your joins will be pushed into the application layer rather than the DB layer so are likely to be slower. Good governance is necessary to ensure this doesn't happen.
Best Answer
"This table has the appropriate indecies but is becoming a major hangup when running queries"
Partitioning alone doesn't help query performance unless SQL Server is able to eliminate partitions when running a query. Your WHERE clause needs to line up with the way you partition. We only get one field to use as a partitioning field, so if that field isn't included in your WHERE clause, you're still likely to scan the entire table despite having partitions.
"and just because of its size."
Partitioning can make certain maintenance operations easier, but there's still things we can't do on a partition-by-partition basis. If index maintenance and stats updates are causing you problems, you're better off splitting the design into an archive table and a live-updated table. When you need to periodically move data from the live table to the archive table, you do that, rebuild the indexes with 100% fill factor, update stats with full scan, and then set its filegroup to read-only. Partitioning can help with archive table loads - but partitioning the live table may not. (I'm tossing out several advanced concepts here as if it's quick and simple, but I'm just sketching out some background here.)
"It appears that using the partitioning would require less code changes."
Sorta kinda - it looks that way at first glance, but the more you get into it, you've got options like partitioned views. You can rename the existing table, put in a view in its place, and then you can make your own changes to the underlying tables (and add multiple tables) without changing your app.
I've written more about the pitfalls of partitioning here:
http://www.brentozar.com/archive/2008/06/sql-server-partitioning-not-the-answer-to-everything/