Motivation

Preferences API covers actually the same use cases as current settings infrastructure in NetBeans but there are many deficiences in settings infrastructure in NetBeans that disqualify it:

missing easy-to-use, instantly ready API
excessive complexity
poor performance
persistent settings are hard connected to implementation (java serialization)
settings infrastructure gradually negates its original advantages

Missing easy-to-use, instantly ready API

There is actually no API dealing with settings in NetBeans. Developers must make it for themselves by subclassing SystemOption. Then they can choose one of following ways how to get their instance:

Lookup.lookup
SharedClassObject.findObject
InstanceCookie.instanceCreate

All these ways are identical but this ambiguity might be confusing especially if the first two ways need dependency on org.openide.util and the last one on org.openide.loaders and org.openide.nodes.

There are additional tasks necessary before one can start to use its subclass of SytemOption:

create settings file with enumaration of all superclasses and interfaces
add registration into layer to let Lookup to find it (might be a little confusing because Lookup's purpose is to be able to make your implementations public and let other modules to looked them up - this doesn't correspond with the fact that SystemOption encapsulates mostly module private settings)

Typo in settings file or in layer won't be traped during build process. Missing propertyChanges is next typical problem that causes that no changes are made persistent. Implication: error prone by design.

Example:
      Preferences prefs = Preferences.userNodeForPackage(getClass());
      
SimpleOption so = (SimpleOption)SharedClassObject.findObject(SimpleOption.class);
          
        public static final class SimpleOption extends SystemOption {
          public String getName() {
            return (String)getProperty("name");
          }
          public void setName(String name) {
            putProperty("name", name, true);
          }
        }

        <?xml version="1.0"?>
        <!DOCTYPE settings PUBLIC "-//NetBeans//DTD Session settings 1.0//EN" "http://www.netbeans.org/dtds/sessionsettings-1_0.dtd">
          <settings version="1.0">
          <module name="org.netbeans.modules.projectui"/>
          <instanceof class="org.openide.util.SharedClassObject"/>
          <instanceof class="org.openide.options.SystemOption"/>
          <instanceof class="org.netbeans.modules.yourproject.SimpleOption"/>
          <instance class="org.netbeans.modules.yourproject.SimpleOption"/>
        </settings>

        <folder name="Services">
          <file name="org-netbeans-modules-yourproject-SimpleOption."settings" url="simpleOption.settings"/>
        </folder>

Excessive complexity

NetBeans settings infrastructure contains aproximately more than 6000 lines which somehow affects maintainance, robustness, performance ...
Involved modules:

org.openide.util
org.openide.options
org.netbeans.modules.settings
org.openide.loaders

Poor performance

Performance of SharedClassObject.findObject is rather poor:

deserialization
looking up for BeanInfo
reflection calls
a few instances of PropertyChangeListener, FileChangeListener are involved
additional objects instantiated for every SystemOption subclass: Lookup, InstanceCookieProvider, SerialDataConvertor, NodeConvertor, SaveSupport....

Persistent settings are hard connected to implementation (java serialization)

Java serialization in settings infrastructure complicates:

import of settings
declaration of default values
reset to default values

To be fair there exists a way how to avoid java serizalization by writing convertors but not well accepted by developers becuase usage of convertors makes developers to write additional code and registration.

Settings infrastructure gradually negates its original advantages

SystemOption seemed to be convenient because developers got for free:

UI based on bean introspection in form of propertysheet
persistence - there was enough to fire propertyChanges

Bringing up convertors plus new Tools/Options infrastructure actually negates original advantages becuase now developers should care about both persistence and UI.