I've not been on shared hosting for some time, but things always used to be this way. It is a combination of using default Apache/PHP/other configuration (as provided by the off-the-shelf hosting control panels), default file+directory permissions, and users not being educated to change the permissions on sensitive files (or better: being educated enough to know tweaking those perms is not enough so they should demand a more secure setup from their host).
If I'm reading between the lines well enough, I suspect the problem is that
/home/ is globally readable (which is pretty much standard) which allows you to see what users exist as they all have a directory under
/home/. If this is the case then the fix they applied was likely to simply change the read permission flag on
/home so that you can not list the contents, which isn't really a fix at all: if you know a username either because of foreknowledge or by finding a list of users from elsewhere (/etc/passwd for instance, which usually globally readable) then you can just list
/home/ and blocking reading of
/home won't change that. Turning off global execute permission on
/home would stop you, but because of the way many shared hosts are configured that would also break Apache. Yoiu can test this if you report the issue and it gets fixed the same way: remember one of the usernames you can find now and after the fix see if you can still read
/home//public_html or similar.
If you host runs Apache as a single user then there is no way around this. You can mitigate it somewhat with carefully setting permissions on your own files and some obfuscation of file/directory names, but that isn't really a proper answer to the problem.
Apache can be configured to run scripts (via suexec, phpsuexec, and so forth) as a the owner of the script which allows you to lock down configuration files and others that contain sensitive information so other uses can't read them (only set them to -rw------- and only you can read them, and that includes scripts if Apache runs them as you) - but most hosts don't do this (or they didn't last time I was working in that arena) as it is more hassle to setup and/or because it requires more resources. And by "more hassle to setup" I simply mean that it means more than just the out-of-the-box configuration: the "leading" standard control panel back than was cPanel (it may still be, I've not kept an eye on the market recently) and seeing posts like
http://www.linuxgo.net/howto-enable-suphpphpsuexec-on-a-cpanel-server/ indicates that it still does not offer an easy (from the point-and-click PoV most cheap hosts need as they are rarely Linux/Apache/other experts) route to using the more secure arrangement. Most hosts will consider the extra admin time of setting up the more secure options to not be worth keeping (or gaining) your custom - 99%+ of their target market don't care (or don't know any better) and spending time to satisfy the other 1% or less is not worth it to them.
tl;dr: You will probably find this is the standard setup on a great many shared hosts, possibly most, maybe even nearly all. To ensure you are getting a new host that does things more securely when you move, you need to ask some pre-sales questions that are fairly technical (in the sense that sales may not be able to help, unless the company is small enough that the sales and tech support teams are the same people).
I would suggest instead using a VPS provider or self-hosting, that way there are no other direct users of the machine (be it real or virtual) to worry about, but unfortunately both of those options put more administrative load (and cost, unless you are paying far too much for shared hosting) on yourself and can be a minefield of its own (as with shared hosting avoid the cheapest options and ask searching questions when signing up - FYI of the providers I used before I had my stuff on dedicated machines here and externally, Linode were the outfit I'd most readily recommend (by a fair margin) though they we a bit more expensive than the others I used).
Still tl;dr: Shared hosting is generally not secure. There is little you can do about it other than move to using a different type of hosting service.