All things being equal, I prefer a language where I can make that decision based on the design, over a language that makes the decision for me.
Yes, but is working with pointers explicitly really necessary for the level of abstraction you're working at? While it is certainly important in systems programming to be able to get at the low-level implementation details, why should a programmer be aware of pointers - or even references - when writing applications? Seriously, in most apps, if you have to deal with any data structures at a level of abstraction below that of a list, heap, or bag, then you're probably working at too low a level of abstraction.
This is my real problem with hybrid languages like C++, Java, Ada, Object Pascal, etc.: they try to have both the efficiency of a systems language and the abstraction of a very high-level language, but to achieve neither. IMAO, it would be better to use a very-high-level language (e.g., Lisp, Smalltalk, ML, Erlang), and use C or assembly for post-optimization, than to try and split the difference through the whole program and end up with the sort of mess that is all too common with current systems. It isn't a matter of 'paradigmatic purity'; it's a matter of not having to pay attention to implementation details which are irrelevent to the task at hand. Writing code in C++ is like laying out a building blueprint where you need to specify the exact location of each nail or bolt or risk structural failure. There are times when the details need to be laid out precisely, but most of the time, having to do so is just a costly distraction. I wish that software houses would see how much time, money and effort they waste with these 'modern' languages.
Of course, wishing this and expecting it to ever be done are two different things, which is why I'm currently studying for the SCJP...