In small systems... duplicate away... if you have no intention of scaling up and performance is not a potential issue to you. Now on a moral\ethical and straight up 'why would you do that', databases should be designed properly because as the dba\developer you are told one thing. Then when sales gets ahold of this new product that is designed for small customers they go and sell it to the largest customer in the folio. I have had to deal with this numerous times from customers using databases which were meant to temporarily hold banking transactions\images which decide they are a great archive solution and then complain about performance. Your design needs to be robust enough to go a bit above what the product spec sheet says is acceptable use just to aid you in future growth and troubleshooting. Sales should be slapped for doing such things but maybe there is a valid reason.
Back closer to topic... Even if you have multiple disks with the indexes on each you will still end up with higher reads and with higher memory loads. Your best bet is to definitely get rid of the true dup index and even some of the tertiary indexes based on the data within.
ColA, ColC, ColB
ColA is a 10 digit account number
ColB is the uique identifier -- in this case Integer -- used to cross to different tables.
ColC is either 1,2,3, or 4 and there are 15 million items it is not very discrete.
Based on how your application queries data it woudl be foolish to not get rid of ColA, ColC as it is a direct duplicate and ColC is minimal in length. From my experience i would also get rid of ColA,ColB as ColC is minimal in length and even though SQL Server will still utilize it, there is a performance gain on forcing it to ColA,ColC,ColB. As for the index on ColC alone... This has proven beneficial and issue on some of the systems i support. It truly depends on the system, hardware, scale, userbase, load etc. I have had instances to remove it and to leave it. Due to the fact that you almost always require cross referencing to another table in a join then ColC alone can be removed as you will almost always have ColB and ColC together in your queries atleast for the application.
WHenever i do performance work it is treated as a special case. I utilize what i have learned previously but no 2 databases (even for the same app) at 2 sites are the same. They have different workloads (even if minimal) which can drastically effect your findings. There are good default indexes to create but once your system gets larger then some customization may be necessary. It is hard to explain to customers that SQL Server has it's own brain and sometimes it doesn't necessarily solve the maze correctly of getting your data back. It will work succesfully but there may be a better path.