Configuration schema was originally introduced to help describe configuration for translations. Then it expanded considerably and is now used to export configuration entities automatically for example (unless you want to write code to manually define what to export). Configuration schema is also used to automatically typecast values to their expected types. This ensures that although PHP and web forms in general favour strings over all other types, the right types are used when saving configuration. That is important so when deploying configuration, only actual changes will show up in the difference, no random type changes. Schema enforces certain rules and best practices of configuration on its users, for example that each piece in the active configuration should have an owner. Finally configuration schema based configuration validation helps find several types of bugs in code that is otherwise not or incorrectly tested.
Therefore after a month+ of work to make all core tests pass strict configuration schema checking, we are making TestBase default to strictly check all configuration against configuration schemas. There are only a few tests exempt from this in the testing of the configuration system itself. This affects all contributed module developers writing TestBase (WebTestBase, KernelTestBase, etc.) extending tests. This may result in new test failures which indicate either issues in your schema, your configuration, your tests, migrations, etc. Either way it indicates that in some cases unexpected data structures are generated.