My two cents and a couple of things to note. My DBA's tell me, and is what I use to determine how to provision space, is that the max oracle data file size is 32GB, so each time they need to add space it will occur in 32GB chunks. As a best practice we create multiple database VV's and we keep them all the same size, if I grow one I grow them all for consistency and predictability. Here, we run Oracle on Windows so it's rather easy to add space without impact, it appears you are deploying on Red hat so if you add space to a VV it will be created as an extent which after time could introduce performance issues.
I would recommend working with your DBA's and agreeing on a max VV size, in my case we deploy in 1.5TB increments on our large servers, 500GB increments in our medium and 250GB on our smaller, this of course is barring the tiny one offs. We also start out with four DB LUNs on each server and it is up to them to round robin the creation of the data files. Since everything is thin provisioned I'm not wasting space and I'm ensuring that I can guarantee performance out of the gate.
Also, like you, we also dedicate LUNs to redo and achieve, however we only have a single LUN for archive, we have not seen a need to have multiple outside of our asynced copies.
I also came from the EVA world and I think you will be pleased with the performance you will receive by moving to 3PAR. If you haven't read it yet HPE published a technical whitepaper for EVA admins
http://691d3755c7515ca23f7b-dbfc12bd0c567183709648093997d459.r57.cf1.rackcdn.com/assets/en/4aa4-3999enw-an-introduction-to-hp-3par-storeserve-for-eva-administrator-version-2.pdfIn the end I make it my business to work closely with my SQL, Oracle and SAP engineers and admins to collectively design tailored best practice implementations as our core business runs on these platforms.