Kobo introduced kepub originally using the ACCESS renderer for rendering epub3 Japanese language ebooks since at that time, Adobe's RMSDK was rather poor (and I am being kind at saying rather poor) at rendering ePub3. Even the latest RMSDK still lags the Webkit based renderer that Kobo now uses in many ePub3 features. OTOH, to manage ebooks using Adobe's ADEPT DRM which is very common, Kobo had to either write their own code for managing ADEPT DRM or continue using RMSDK.
Personally, I use the standard ePub for most books since it has (IMNSHO) superior font and typography management. For those few ePubs where there are multiple large images, I will convert to kepub to allow use of it's ability to zoom images. A very small subset of the ePubs I own are ePub3 FLO (fixed layout) ebooks where the WebKit based renderer handles them much better than RMSDK (again being kind to RMSDK).
Another reason for kepub is that it uses Kobo's own DRM which saves them from paying Adobe for any ePubs synced to your ereader/app directly from Kobo.
BTW, if you ever want to get a headache, take a look at Japanese typography where you can use right to left or left to right, top to bottom or horizontal lines with 4 different sets of glyphs (native Hiragana, Katakana, and Kanji plus for other languages Rōmaji). Add in ruby for such things as giving the pronunciation of Kanji since Kanji ideograms can have multiple pronunciations.
One example of Kanji where ruby would be used would be the 4 women's names below:
- 淳子 (Akiko)
- 淳子 (Atsuko)
- 淳子 (Junko)
- 淳子 (Kiyoko)