I have to respectfully disagree – if the goal is to make refactoring (of anything, not just database tables) easier, then it's important that the most well-connected elements in your 'dependency tree' be stable (i.e. 'abstract'). An additional 'abstraction layer' doesn't necessarily imply that the difficulty or duration of refactoring database table designs is any less. A "native SQL Server abstraction layer" could require more work to be done because of refactored database tables than an appropriately DRY set of application components. Why are you assuming that SQL Server views or stored procedures are inherently easier to change than other application code items?

The more generally applicable goal should be to minimize 'redundant' references in all of your code (and I include database table designs as 'code'), all else being equal.

I suspect, as this is a very database-oriented site, that you're implicitly assuming that their are separate sets of responsibility for the application database and its other components. In which case it very well be more productive to maintain an explicit interface between the database and the other components – but that doesn't mean that refactoring is necessarily any easier than if such an interface is not maintained.