Everyone warns against shrinking a database, but will it work in my case? 1 GB db with tables removed now 100 MB Everyone is warning against shrinking a database, e.g. 
SQLAuthority

But will it be a valid option in my case? The database was originally more than 1 GB,
but with a table removed from it (moved to another database), the database is now 100 MB when I do a backup of it, as opposed to the MDF being more than 1 GB still.

What if I shrink the DB, then rebuild all the indexes? Is all of this still taboo?
A 1 GB database is next to nothing as far as storage is concerned.  If you are really looking to save space at that level, I'd be apt to question the environment specifics.  Even on a small box, 1 GB is negligible.

I recommend you read up on the pit falls of shrinking your database files (more specifically your data file[s]).  Paul Randal wrote a great article on this very topic.  The moral here is to know what is happening and what you are doing to your data.  If that is acceptable, and the business demands the smaller database then proceed cautiously.  I will quote Paul Randal with his recommended practice in a situation like this:


  So what if you do need to run a shrink? For instance, if you’ve deleted a large proportion of a very large database and the database isn’t likely to grow, or you need to empty a file before removing it?
  
  The method I like to recommend is as follows:
   - Create a new filegroup
   - Move all affected tables and indexes into the new filegroup using the CREATE INDEX … WITH (DROP_EXISTING = ON) ON  syntax, to move the tables and remove fragmentation from them at the same time
   - Drop the old filegroup that you were going to shrink anyway (or shrink it way down if its the primary filegroup)
  
  Basically you need to provision some more space before you can shrink the old files, but it’s a much cleaner mechanism.


Will your database never need to grow to this size again?  This is the main question that should be on the forefront of your mind when you consider shrinking a database.  It's all about proper sizing, not just for today, but for the long-term foreseeable future.

And, most importantly, do not make this part of routine maintenance.  For reasons why, see Paul's blog post.