One of the great benefits of the strong typing of Apex is system integrity enforcement. By dropping to use of dynamic Apex you lose this tremendous benefit.

In your sample above you are putting a value into the sobject – presumably for later insert or update. If the field is an autonumber this code will actually fail at runtime because autonumbers are not editable – something the compiler tells you long before the code is ever deployed in the case of a static reference.

Given the current restrictions around the standard name field on custom objects this approach is seemingly benign when the reference in code is read-only, i.e. there is no attempt to insert/update/upsert the value but this is a special case.

If the pattern continues and is applied to custom fields then there is no stopping anyone with appropriate permissions from unknowingly renaming or deleting the field and thus breaking the code that depends on it.

Dynamic Apex is meant for use by code that is unaware of what it needs at compile time.