People have claimed that they will actually have the app running and it will say it can't connect. Their phones are not "asleep".
I think most of those reports were Android, though.
Android and iOS have wildly differing implementations of Bluetooth, and Android has differing implementations of Bluetooth across manufacturers. For instance, code which worked 100% reliably on a Samsung Galaxy S8+ had a 20% failure rate to connect on a OnePlus device. Code that worked 100% reliably on a Pixel failed _entirely_ on one LG device.
In my experience as a developer on (and user of) both platforms, iOS has a much more solid implementation of Bluetooth Low Energy simply because Apple's made CoreBluetooth a major selling point to developers. It has quirks, but they're more like 'discovery of devices takes longer when the phone is asleep' or 'peripheral advertisement intervals are vastly reduced when the phone is asleep'. I'd bet that if your iPhone is awake and the app is running, the keyfob functionality is pretty solid.
Android exposes a lot more functionality—you can get at the raw advertisement packets, you can add service-specific data when you're being a peripheral, etc.—but there's also a lot more strange (and often undocumented) quirks. For instance, if you scan too often, Android simply temporarily—and silently—throttles the ability to find Bluetooth devices to spare battery life; in my experience you can have an app that's perfectly coded, have it open and active, even be staring at the screen, and some other app entirely has caused your Android Bluetooth stack to temporarily die.
I suspect Tesla's falling afoul of these various quirks, especially on Android.
Yes, there _are_ some semi-reliable ways to use a phone like a keyfob, particularly on iOS, but it's not a simple problem to solve, and it's a problem you tend to have to revisit and re-solve each time a new OS comes out. So even if they get it 100% reliable on Android Oreo, when Android P comes out, it could very well break.
I like the idea of phone as keyfob, honestly, but I think right now it's using the technology in a manner that isn't really "per manufacturer spec", inasmuch as Apple and Google do not particularly take pains to keep from breaking such implementations across OS revisions (nor do Android vendors take particular pains to make such functionality work reliably in their own Bluetooth stacks). It's just not one of the primary use cases, and so it's not as heavily tested when code is changed or ported.
Given that, a dedicated keyfob probably isn't a bad way to hedge their bets.