In addition to what Jamie said
if you start without a feature definition file a feature guid will be generated. If you later decide to implement a feature definition then you should copy the previously generated guid into the feature definition file so that the feature guid does not change, otherwise adding a feature definition file for an existing feature with a new guid would create a duplicate of the feature with a different guid than the original and this would cause conflicts.
I usually also put the same feature guid in the business class or somewhere as a static property that I can use in code. For features with supporting pages for example you will usually need to know the feature guid to enforce security. ie your supporting page would take advantage of methods in mojoBasePage as in this code snippet from the blog edit page:
LoadParams();
if (!UserCanEditModule(moduleId, Blog.FeatureGuid))
{
SiteUtils.RedirectToAccessDeniedPage(this);
return;
}
UserCanEditModule is a method in the mojoBasePage class, it sees the page id in the url and the passed in module id and feature guid are needed to determine if the user can edit or not. The user can edit if he has edit permission on the page or edit permission on the module and the module exists on the page. The feature guid is needed otherwise a user could manipulate the url passing in a different module id or page id that he has permission on, it is checked against the feature guid of the module instance to make sure it matches.
The feature definition file can add new module settings after the feature is already installed (ie on upgrades), it is processed every time the setup page is visited to make sure that all the module settings in the file exist in the mp_ModuleDefinitionSettings table. You can also update the default value for an existing setting by changing it in the feature definition and visiting setup but that default is only what is used when new instances of the feature are created, it does not update settings on existing instances and existing instances only get the new settings the next time you save the module settings on the instance. Removing a module settings from the file also will not delete it from the database, that would have to be done from an upgrade script.
In your own features you are free to use or not use resx files as you see fit, our features do use them and do need them.
Just before we are ready to make the next release I plan to go through and change as many of our existing dependencies to use NuGet and will update to the latest versions of libraries like NewtonSoft.Json. Our add on products need to be updated at the same time since they often depend on the same libraries so I have to be careful about the timing of such changes. If I updated the mojoportal repository today with those changes it would break things for anyone working with the latest code that also uses our add on features since they would still expect the older versions. So I need to have updated packages of all the products ready at the same time as the next release to do this.