TL;DR: In D365, use SP_RemoveTable instead of DROP.

Every now and then, whether it's your fault or not, a table is going to get FUBAR in your DEV environment.  The rest of the world will keep spinning, and no one will care about the catastrophic problem that only you have.  

One of the cool things about AX has always been if you delete files, or drop a table, a simple AOS restart will bring them back.  You need to be a little extra careful in D365.  Recently I got an ISV update that caused my DB sych to break, ultimately because it was trying to add new the same fields to the SQLDictionary twice, causing a unique index violation.  A great problem for one person to have.

If you don't care about the data in the table, a nice old fashioned SQL DROP can get you halfway to "fixing" a DB synch – however it's very possible that your table won't be recreated on your next DB synch.  A DB synch will never complete if the environment has missing [deleted] objects while references to those objects still exist in the SQLDictionary.  Herein lies the golden nugget of the story, SP_RemoveTable.  SP_RemoveTable is a great, safe way to remove all of a table's references from the SQLDictionary table.  Next time you're ready to crush some tables, use SP_RemoveTable.