The two controllers that are available to you are:

• StandardController
• StandardSetController

StandardController

From the docs: A Visualforce controller is a set of instructions that specify what happens when a user interacts with the components specified in associated Visualforce markup, such as when a user clicks a button or link. Controllers also provide access to the data that should be displayed in a page, and can modify component behavior.

You can find more information here, but basically a StandardController is for ONE record, i.e. if you'd like to create a new Visualforce page for a single record, you'd use a Standard Controller in your Apex. For example:

public with sharing class MyController {
    private ApexPages.StandardController controller;

    public MyController(ApexPages.StandardController controller) {
        this.controller = controller;
    }   

    // maybe this gets called from a button within your VF page
    public void doSomethingWithSingleRecord() {
        SObject record = controller.getRecord();

        record.put('Status__c', true);
        update record;
    }

}

StandardSetController

From the docs: Standard list controllers allow you to create Visualforce pages that can display or act on a set of records. Examples of existing Salesforce pages that work with a set of records include list pages, related lists, and mass action pages.

You can find more information here, but basically Set (list) controllers are for MULTIPLE (or a list of) records, i.e. if you'd like to create a new Visualforce page for a List of records (or even from a selection of records on a List view), you'd use a Standard Set Controller in your Apex. For example:

public with sharing class MyController {
    private ApexPages.StandardSetController setController;

    public MyController(ApexPages.StandardSetController setController) {
        this.setController = setController;
    }

    //maybe this gets called from a button on your list view
    public void doSomethingWithMultipleRecords() {
        List<SObject> records = setController.getSelected();

        for(SObject record : records) {
            record.put('Status__c', true);
        }

        update records;
    }
}

In addition to what everyone else has said...

The helper is designed to have shared code in it. So, you could have code shared by your renderer and your controller or by multiple controller functions. That should go in the helper JS file.

I think that a good practice is to let the controller respond to events, possibly perform some amount of control flow, and delegate business logic to the helper as a separation of concerns. It also sets you up to be able to reuse your business logic in other parts of the component in the future.

Helper code can be shared among components when they are related through inheritance. If one component extends another it inherits its super component's helper and can override it.

Sub components can call super component controller methods, but that may be deprecated in the future according to the documentation in the Lightning Components Developer's Guide.

Components can communicate with each other via events to "share" code. For example, if you have a component that handles writing business logic errors in a uniform way in your app, and handles some sort of error related event, you could fire an event to trigger it to handle an error.