If your game is going to be remotely hardware intensive then you need threads to cope with all modern hardware; future CPUs coming out in the next year or two are starting to make 4 cores the minimum and up to 16 cores common for enthusiast/performance markets. If you're doing any multi-threading at all, definitely do a task-oriented architecture as any other threading model is inherently broken for forward-looking game engines.
Now keep in mind that by "tasks" I mean "jobs" and not "separate threads for different engine subsystems." You absolutely completely do not want to do something like having one graphics thread, one physics thread, one AI thread, etc. That doesn't scale beyond a tiny handful of cores and it doesn't actually gain you any real parallelism anyway. Physics shouldn't run more than one update per AI update (you want your AI to be able to react to physics events), and graphics has almost nothing new to render if physics hasn't run, so each subsystem naturally runs in a sequenced order. You don't even get any benefits out of having physics update the next iteration of the simulation while graphics is running the current iteration because there is so much data shared between the two that you either need lots of duplicated data structures (and the costs of copying from one to the other) or you end up with bad lock contention in shared data structure synchronization code.
What you want is to do is this. Create a thread spool. Run your game loop with the classic sequence of subsystem updates. However, for each subsystem, separate the workload into distinct separable batches, and distribute those to the thread pool. Wait for all jobs to complete before running the next state of the game update loop. Some subsystems may have multiple substages; e.g., graphics may issue a series of jobs to do culling and then a second series of jobs to do render queue creation. This approach avoids the synchronization problem of the first approach, scales to much larger numbers of cores, and frankly is just easier to code, debug, and maintain.