Там свойства есть, но почему-то они нарушают правило именования CamelCase

По идее там Паскаль-кейс

Вобщем, свойства там с маленькой буквы, данные и методы должны быть открытыми, чтобы быть видны в самом Юнити.

Если придерживаться шаблона MVVM или в принципе разделения на слои, то логично. По разным причинам у слоя с графикой (вью) могут быть свои требования к оформлению кода и как и какие данные должны быть объявлены. Поэтому пишется своя вью модель для каждого типа представлений - для адаптации данных модели к представлению. Для Юнити вот такие требования, как выше, для WPF - свои, типа реализации INotifyPropertyChanged, команд и т.п.

Можно написать приложение многослойное, где в одной сборке будет общая логика и несколько сборок - под разные типы клиентской графики (WPF, веб, Юнити). В моём проекте были такие слои как DB (MS SQL Server), ORM (C# Entity Framework Code First), Model (C#), DTO (C#, JSON), View Model (C#), View (WPF, HTML, JS, CSS), ну и слой для общения с железками Лабвью, где была бинарная сериализация по кастомному протоколу.