What is the advantage of using numeric primary keys in a relational database?
Size is one consideration, certainly.  Consider not only the size of the index in the widgets table, but also that primary keys show up in other tables as foreign keys.  In some systems, even short strings are going to take up more space than integers (e.g., MSSQL:  VARCHAR is a byte per character plus 2 bytes, so at only two characters you're already as large as an integer).

Almost all numeric primary keys I have seen are surrogate keys, implemented via series, sequence, auto_increment, IDENTITY or whatever the database engine's native method is for generating values itself.  I suspect this is a leading reason for the ubiquity of the numeric primary key.  One advantage to surrogate keys is that they have no business meaning.  Since business meaning can change over time, using a key without business meaning helps ensure that the primary key is static.

If your widgets have some sort of industry-standard identifier (like the auto industry's VIN, publishing's ISBN, UPCs and so forth), that's probably the best choice for your primary key.  My concern in using widget_name is that attribute's immutability.  Will it ever change?  How do you know it will never change--did Sales tell you that?  :)

The whole surrogate vs. natural key issue is nearly a religious debate, and is sort of tangential to your question.  I would say if you have a natural key that is static, minimal, and unique, use it.  Otherwise, consider a surrogate key (which is likely going to be numeric).