Castle.Core DictionaryAdapterFactory is a very usefull way to easily map AppSettings to strongly typed entities.
Also there are a lot of solutions based on it with enhanced functionality like this:
https://github.com/TroyGoode/ConfigReader
The only thing I dislike is an interface restriction. I still cannot understand what is the point to have interface for each settings entity. That's why I'm asking about it's alternatives without interface limitation.
The Castle dictionary adapter uses castle-dynamicproxy in the background; what the dynamic proxy does is that it creates a concrete object based on an interface. It then intercepts calls to this interface and translates them into calls to the concrete object or to whatever data store is applicable; in our case the settings from the configuration file
So this architecture must rely on an interface as it is the basis upon which the proxy will be built. If you really want to use an object, you can start from a concrete object and then refactor in your IDE to extract interfaces from it, but unless you are willing to rewrite some code there is no out of the box way to force the DictionaryAdapter to play with a non interface
If you write some code you may want to explore one interesting attribute of the dynamicproxy, which is that it is not able to intercept methods / properties, unless they are virtual; you may have a concrete object with virtual properties and intercepts its calls in order to return data from the configuration.
However seeing all the work that would be needed I would recommend that you bite the bullet and continue using the interfaces for your configuration.