This is just another case of poor fill rate performance. We see people running in to this a lot.
Intel GPUs (which most MacBooks have) have pretty low fill rate capacity. The project provided uses two force-own-texture layers, and enough content is displayed to count as another fullscreen draw, and then there's usually the overhead of a fullscreen draw to copy the game to the display. So it's at least 4x fullscreen draws per frame. On a high-DPI 2K display, one fullscreen draw alone will copy 3.7 million pixels, or around 14.7mb of data. The project does that four times, so it's about 59mb overhead per frame. If you want to reach 60 FPS, that means 3.5 GB/sec of GPU bandwidth.
Presumably the Intel GPUs have a memory bandwidth lower than 3.5 GB/sec, so you can't hit 60 FPS.
This is nothing to do with the fact your game is "only" 256x144: once you enable "high quality" fullscreen mode, it's rendering everything - including every layer - at full-whack 2560x1440 resolution. That's what "high quality" fullscreen mode is for! For this kind of game you really ought to use "low quality" fullscreen mode to avoid wasting GPU bandwidth - since that really will render the entire game at 256x144 (which is so small the performance overhead is probably negligible), then stretch the game up to the full-res 2560x1440 once at the end, meaning there is only 1x fullscreen draw overhead. That's probably at least 4x more efficient than your current high-quality fullscreen mode approach.
By the way this is nothing to do with HTML5, browsers, Construct or anything else - you've hit a hardware limit. A native app would perform the same. 3D games are designed to perform minimal overdraw so don't tend to run in to run in to fill rate limits so much.
Since a lot of Construct users end up having trouble with this, the new C3 manual's performance tips section was recently rewritten to focus a lot more on fill rate.