Why are these two queries having such different executions?
LEFT is killing performance; remove it unless you have a good reason for keeping it.  To elaborate...

((but first... The purpose for the LEFT was missing from the original query; this answer assumes the LEFT was not necessary.))

LEFT JOIN says that you want data from the right table, whether or not there was a match with the left table.

JOIN says to display only the rows that match (via ON) both tables.

(OUTER is optional and adds no semantics.)

If you are running a version before 5.6, the derived table (subquery in LEFT JOIN) will have no index, so it must be scanned repeatedly.  This is a big reason to get rid of LEFT.

Without the LEFT, the Optimizer is likely to evaluate the subquery once, then efficiently JOIN to reporter to finish the query.

For JOIN, the inner query needs this composite (and covering) index INDEX(messagetypeenum, createdOn, reporterid).

There is another technique (I think)...  Get rid of the inner SELECT, simply JOIN (or LEFT JOIN) to the table:

select  r.*
    from  reporter r
    left join  nubamessage m  ON m.reporterid = r.id
      AND  m.messagetypeenum = 7
      and  m.createdOn &gt;= '2016-06-18 00:00:00'
      and  m.createdOn &lt;= '2016-06-18 09:30:00'
    WHERE  r.enabled = 1
      AND  m.reporterid is null;


In this case, it may needs INDEX(reporterid, messagetypeenum, createdOn).

Yet another variant would use EXISTS and, I think, provides the equivalent of the LEFT

select  r.*
    from  reporter r
    WHERE  r.enabled=1
      AND NOT EXISTS 
    (
        SELECT  *
            from  nubamessage m
            where  m.messagetypeenum =7
              and  m.createdOn&gt;='2016-06-18 00:00:00'
              and  m.createdOn&lt;='2016-06-18 09:30:00'
              AND  m.reporterid=r.id 
    ) 


I can't predict which variant will be fastest.  It partially depends on how "many" in the many:1 mapping of m.reporterid : r.id.