Ніхто не каже що він щось продає. Статтю треба позначати як pet project, або prototype. В кінці додати висновок що на реальному проекті таке не робити, бо є такі плюси і мінуси :)
DOU читають різні за досвідом люди, тому початківцям бажано зазначити, що так робити на комерційному проекті не бажано, бо це може спричинити додаткові проблеми, які буде в рази складніше вирішити ніж з дефолтним компонентом.
Математика — круто, ініціатива — теж (в конкретному прикладі), але треба розуміти що є тех завдання і його треба робити за принципом KISS (YAGNI).
Без цього висновку стаття мотивуватиме початківців писати складні, в більшості випадків непотрібні рішення замість використання існуючих компонентів, що в свою чергу породжує більшу ймовірність дефектів, а також ускладнює адаптування коду під нову версію операційної системи :)

Враження двоякі.
З однієї сторони — молодець, що спробував написати щось кастомне і можливо це буде цікаво новачкам. А з іншої — це не практичне рішення, яке забирає час на розробку, тестування та й не універсальне.

Чи є в контрола шанс на reuse? — ні.
Цей контрол треба буде допрацювати для випадків Accessibility, Dark mode, щоб зробити його потенційно можливим для масового використання.
А обмеження по кількості елементів — великий мінус дизайну компонента, через який він так і не буде використаний іншими.

P.S. Keep it simple, не треба робити оver engineering :)

не только для них

Все ясно, джинса. Розходимось. Ті ж ріелтори, але тепер ще віджимають вільні мегабайти з твого телефону ;)