I might be stating the obvious here, but parallel query is not a magic fix for all types of performance problems. Consider these two situations:
1. You have 32 CPUs (or cores), your query is not using parallel execution yet it is using 100% of one CPU (or core), the overall CPU utilization average is 50%, and the IO subsystem is not heavily utilized.
2. You have 32 CPUs (or cores), your query is not using parallel execution yet it is using 100% of one CPU (or core), the overall CPU utilization average is 50%, and the IO subsystem is nearly 100% utilized (either maximum number of I/Os per second or maximum throughput).

How might the outcome be different in both of the situations if parallel query is enabled?

It is quite possible that the first two queries that you helped with parallel query were in fact CPU bound (the single CPU utilized was the bottleneck), while the remaining queries were I/O bound (the I/O subsystem was the bottleneck). In either case, it is best not to guess. Instead, capture a 10046 trace at level 8 or 12 for the batch job and determine *why* the other queries execute more slowly when parallelized. You might also capture delta values of V$OSSTAT periodically during the execution of the batch job so that you can see, for instance, if you now have 200 parallel slaves fighting for the 32 CPUs, or if you now have 200 parallel slaves all waiting for I/O.

You might take a look at a couple of other articles by a couple of OakTable Network members:
http://oracle-randolf.blogspot.com/2011/04/things-worth-to-mention-and-remember.html (a three part series)
http://oracledoug.com/serendipity/index.php?/plugin/tag/Parallel (blog category)
http://structureddata.org/category/oracle/parallel-execution/ (blog category)
http://jonathanlewis.wordpress.com/category/oracle/parallel-execution/ (blog category)

Currently bogged with a issue in parallel query tuning.
Prelude – Server – CMT T5120. 32 Cpu’s. The Batch jobs when transferred from old server runs much slow. CMT servers encourage for parallel processing in batch jobs. So when we parallelized 2 queries, it was running much improved time (nearly 1/2 the time taken). But when we started parallelizing the rest, it degraded the performance of the rest.

SQL> sho parameter parallel_

NAME                                 		TYPE        VALUE
------------------------------------ 		----------- ------------------------------
fast_start_parallel_rollback         	string      LOW
parallel_adaptive_multi_user        	 boolean     TRUE
parallel_automatic_tuning            	boolean     FALSE
parallel_execution_message_size      	integer     2152
parallel_instance_group              		string
parallel_max_servers                		 integer     40
parallel_min_percent                		 integer     0
parallel_min_servers                 		integer     0
parallel_server                      		boolean     FALSE
parallel_server_instances            		integer     1
parallel_threads_per_cpu             	integer     2
recovery_parallelism                 		integer     0

Thanks for the compliment.

There was a bit of humor embedded in this article, in case anyone missed it. Just to clarify:
* Don’t run SQL statements in parallel(1000) just to drive the cost of the query toward 0. There were a couple of recent comments on this blog pointing back to an asktom article that partially explains why.
* Don’t try viewing Oracle’s support documents on a shiny new Apple iPad – the iPad does not support Adobe Flash, and well, the new Oracle’s support site is Flashy.

Hopefully, this article provides access to a couple of helpful resources, and might even prompt someone else to write something that is well beyond a light-weight exploration of recent parallel query enhancements.