Using Ant in this way is very sensible. It allows flexibility, but also achieves standardisation.
Ant's immutable properties can be a real pain in the neck. Since you can't change them, you have set another property dynamically inside a task to have any kind of conditional behaviour.
For example, by checking a few obvious paths, you could convievably have a "deploy-to-weblogic" task that figures out which version of Weblogic to use (by what is installed on the system). This can be done with the "if available" tasks, setting some kind of "is weblogic 6.1" property, which is then used as the "if" in a task definition. You call both the "deploy-6.1" and the "deploy-7" tasks, knowing that only one will actually do anything because of the "if" in it's task definition.
If you didn't follow the paragraph above, then you fully understand Ant perils. If you did understand it, then you have the correctly warped mind to handle Ant ;-)
My advice is to have some sort of "init" task which sets up as many conditional properties as possible. Make init a pre-requisite task for all others (ant will ensure it's only run once), and thus, all tasks will get the benefits of conditional properties, as well as "layered" immutable ones too.
Doing anything beyond the simple with Ant requires careful planning - use the force wisely, my young padawan ;-)