This is a complicated question to answer. Part of that choice is a design decision, another part is a matter of convenient development for me at the time I was working on ZeroPhone base, and there are also hardware limitations, let's start with those!
Raspberry Pi has a couple of display interfaces - or interfaces we could use for a display. Let's count - there's DSI, DPI (parallel RGB), HDMI, composite video and SPI, let's get through those.
DSI is supported by many cool displays, like iPhone screens. However, it's not available on Pi Zero, and is out of question for RPi in general - it's locked down, only peripheral that works with it is official Raspberry Pi touchscreen, which is large, expensive and consumes a lot of power. Next!
HDMI is good, it's GPU-accelerated, powerful and compatible with lots of stuff. However, there aren't many small screens compatible with it, it's proprietary-ish and the available HDMI chips don't have the best power consumption. Moreover, Pi Zero has MiniHDMI and it's hard to integrate stuff with this kind of connector. Let's leave it for an external display, next!
Composite video is ubiquitous, has been there for ages and is very cheap. It also has a fundamental video quality cap, and market is full of small shitty screens with no quality ones. The power issue is there, too - not only popular chips for analog video still use 5V, most Chinese product designers would use a linear regulator for in-screen 5V, and say that "it requires 12V" - bam, the power consumption is "horrible" on top of "bad"!
DPI is GPU-accelerated, supported by many displays and actually has software support. However, it would take most of GPIOs we have on a Pi Zero, and most of those aren't re-mappable, meaning we'd lose I2C, SPI, UART and some more cool things.
SPI is what ZeroPhone uses now. It's not GPU-accelerated, but we don't always need that - especially not in the case of a 128x64 monochrome display (though AFAIK it becomes relevant when screen is bigger and a color one). It doesn't use too much power, can reach high enough speeds for quick redraws (unlike I2C, for example) and is compatible with lots of existing displays.
Development and sourcing limitations
When I started this project, in December 2016, I was quite low on money. It was the end of the year when the idea of a wearable assistant was requiring more resources and skills than I had, and pyLCI had most of the features I needed from it. It was time to change my course to a bigger project, something that I could dedicate most of my time to - and a smartphone project was something I could personally get behind. I was looking at eBay, picking screen breakouts to sample, and most of them were unsuitable - by size, by price or by some other characteristic. Some of them were horribly outdated - like the Nokia 3310 display, 84x48 isn't enough when you see just how huge those displays are.
- Ideal display - but not symmetric because it has 7 pins and adjustable header has 8
- Even more ideal display - same, but symmetric!
- Small and no breakout available (though cheap and with color pixels)
- Huge, especially compared to its pixel count
- Small (though interesting for a notification display mod)
- Monochrome, cheap&popular but very small
- Allegedly a color display, but the breakout is the same as 6 (did the seller fool me?)
- Just huge
- Huge and the pinout is crazy
- Absolutely barbaric (for scale)
With the money I had, I bought 3 color OLED panels (I didn't get to make a breakout for them yet), 1 color OLED with a breakout (which I didn't put to use, ultimately), 3 1.3 monochrome OLEDs and 3 TFTs of different pinouts - all ILIxxxx, two 1.8" and one 1.44". When they arrived and I compared them, it became clear which is the main one to be used for now - the 1.3" OLEDs, which you've seen many more times since then =)
Even now, ZeroPhone still has the adjustable headers and backlight PWM pin (unnecessary for OLEDs) - from that time when I wasn't sure about which one I'd have had picked, but would need to make any of them fit well. I'm not sure if this feature is worth keeping at this point - will people use it at all? See, for other screens to work, there'd need to be a driver, and while it wouldn't be too hard (luma.lcd library accepts most of the screens that fit those headers), most of the people aren't going to be concerned about this.
("most of the people aren't going to be concerned about this" - it's a problematic statement, because most of ZeroPhone's features are what most people don't care about. That's why it's so hard for me to leave features out =) )
Vision of the project
There are, I'm sure, billions of phones with touchscreens in this world by now. The thing is - having a large display and a touchscreen isn't the main feature of ZeroPhone, and if we focus on that, we would obviously never win, and we can't compete with any of current mass-produced smartphones by hardware. Thankfully, ZeroPhone is not about hardware, it's about what you can do with it. It's about having control over your smartphone, about using it in scenarios nobody yet thought of and modifying it to suit any task you want it to do. ZeroPhone is a phone you can trust, one that serves you instead of whoever programmed it and whoever designed the apps you run.
When I was designing the current version of ZeroPhone, I understood I had to abandon "large display with touchscreen" for "accesible, Raspberry Pi-based, power-efficient and easy-to-use". Just like ZeroPhone wouldn't really take off without the success of Raspberry Pi, a ZeroPhone with a big display won't be able to take off until there's a good hardware interface for it available, and a suitable display to support it. Hopefully, we'll see some projects like that in the next years =)
Don't get me wrong - powerful hardware is nice to have. However, until we actually can get some to work with, let's squeeze the most out of what we can get ;-)