Since it is the second time you're asking the same question, may I intervene in asking why you're interested in a different data format?
First of all, yes, GTFS is a current standard and is being actively used by most cities around the world for data exchange between stakeholders' apps (eg. from the schedule producing app of the transit agency to customer facing public apps). GTFS is „alive” and being further developed, most of this activity (proposals and changes) can be watched over here - https://github.com/google/transit/issues
If something is missing that you require for your specific project or use case, you can just code your apps to output GTFS and GTFS-Realtime with extra fields. That is not standard-breaking, other apps will just ignore them. For example, extra information about a trip/route/stop time can be stored into a new column you add to the CSV and as long as you code it in both apps they're both going to "see" it. Same applies to GTFS-Realtime. You can add stuff to the .proto file in the extensions area and you can therefore broadcast both standard-compliant GTFS-Realtime data and your extra fields at the same time.
GTFS may not be the best format for applications outside data exchange for planning. For example many display systems (eg. the LED boards you see in stations) use the SIRI (Service Interface for Real Time Information) format which is a spec for creating JSON or XML endpoints with real-time arrivals/departures and alerts.
Since you're asking about smart cities in general, GTFS and/or SIRI are not the be all and end all of it, cities also have bike/scooter/car rental (look into GBFS)
So, the answer to your question greatly depends on what motivated you to ask in the first place. If you feel like something is missing, ask specifically and maybe someone already implemented it in a way and could share that information with you.
I wish you a happy new year with great projects!