Yes, I can think of ramifications - index fragmentation, file fragmentation - and basically, just a waste of time and resources.

If you are constantly shrinking a file - and then it is growing again, that is going to cause file fragmentation. It also causes index fragmentation, which you then have to perform an index rebuild/reorganize to clear up - which will probably cause the file to grow again.

There is absolutely no performance issues with have extra 'white' space available in a database. In fact, it is often desirable to have that space - not only for future growth and to avoid auto growing that file at the worst time (say 8am Monday morning), but also to manage your index rebuilds without having to suffer the wait for the file to grow.

All in all - that is not very good advice.

The only time you should consider shrinking a file is when there has been an extraordinary growth and you know you will never use that space again. For example, you copied the database to a test system - removed most (or all) of the data to build a blank copy. Or, someone ran a bad query that caused the database to double in size, etc...