Custom Post Type Capabilities Singular/Plural

As is often the case, the answer lies in the documentation. In the documentation for register_post_type() you'll see:

• 'capability_type'
  (string) The string to use to build the read, edit, and delete capabilities. May be passed as an array to allow for alternative plurals when using this argument as a base to construct the capabilities, e.g. array('story', 'stories'). Default 'post'.
• 'capabilities'
  (array) Array of capabilities for this post type. $capability_type is used as a base to construct capabilities by default. See get_post_type_capabilities().

So capability_type uses the singular and plural strings provided to fill the capabilities argument, and if we follow that link to the documentation for get_post_type_capabilities() we can see the full list of capabilities (emphasis mine):

By default, seven keys are accepted as part of the capabilities array:

• edit_post, read_post, and delete_post are meta capabilities, which are then generally mapped to corresponding primitive capabilities depending on the context, which would be the post being edited/read/deleted and the user or role being checked. Thus these capabilities would generally not be granted directly to users or roles.
• edit_posts – Controls whether objects of this post type can be edited.
• edit_others_posts – Controls whether objects of this type owned by other users can be edited. If the post type does not support an author, then this will behave like edit_posts.
• publish_posts – Controls publishing objects of this post type.
• read_private_posts – Controls whether private objects can be read.

These four primitive capabilities are checked in core in various locations. There are also seven other primitive capabilities which are not referenced directly in core, except in map_meta_cap(), which takes the three aforementioned meta capabilities and translates them into one or more primitive capabilities that must then be checked against the user or role, depending on the context.

• read – Controls whether objects of this post type can be read.
• delete_posts – Controls whether objects of this post type can be deleted.
• delete_private_posts – Controls whether private objects can be deleted.
• delete_published_posts – Controls whether published objects can be deleted.
• delete_others_posts – Controls whether objects owned by other users can be can be deleted. If the post type does not support an author, then this will behave like delete_posts.
• edit_private_posts – Controls whether private objects can be edited.
• edit_published_posts – Controls whether published objects can be edited.

So by passing ['event','events'] all those capabilities with post will created but with event (eg. edit_event), and all the capabilities with posts will be created but with events (eg. edit_events). However, note that just passing 'event' to capability_type will have the exact same result. This is because if only a single value is passed WordPress will automatically add s for the plural. The only reason you'd need to pass the singular and plural versions separately is if the plural version is not just the same plus "s", such as story vs stories (if you only passed 'story' then the plural capabilities would be like edit_storys).