The 'organic' palettes you see many use here are almost always hand made as you work and I would say almost impossible to pre design without as you show having a huge panel.

There is nothing wrong with linear ramps in apps. Those that use the more organic method are able to roughly see where a shade is shared or shareable.

I wouldn't worry too much about this, imo.

ps: seems like the palette you show has many wasted shades with far too many 'whites' and not enough neutralizer shades.

I've put some thought into this problem in the past. Your post prompted me to rethink it a bit..

First off, one of the main obstacles that such an interface faces is complexity. If you give the user too much control, then they need to.. remember too many controls ;). So, with a few things in mind, I'll suggest some limitations on the problem:

* Users cannot reposition colors in a 2d way, only in a 1d way (A color has an index / indices within one or more ramps; it doesn't, in a user-facing sense, have an X and Y coordinate.). This reduces the number of different actions needed.
* A given color can only be connected to a maximum of 4 other colors. This is connected with the need to 'pack' ramps into a grid -- 8 way connectedness might be possible but AFAICS could not be as clearly shown as 4-way connectedness.

The visual representation I am thinking of here is a 'maze', with 'walls' representing cells that are NOT connected
(cells that *are* connected can have a 'wall' that is colored a mix of the two colors that are connected. Cells that *aren't* can just be represented as a color that contrasts both colors reasonably well -- probably a grey)
. The problem of packing the graph into 'maze' format can be viewed as a variant of a 'Box Packing' problem , which is a well known type of problem with a range of implementations already out there.  The palette you show above could probably be packed into about 10x10 cells using this method.

A nice way of visualizing how it would work might be to imagine a bunch of connected Nibbler-style "snakes", that can 'turn' as many times as necessary to fit into the available space, and are only constrained by the need for all 2-or-3-ramp 'junctions' to be located in a way that maintains the entire 'maze' as a single contiguous shape.
Or not -- that explanation got away from me.

Supposing you went with the above basis. This would mean the following user interaction methods would be needed
* add a new color
* edit a color
* remove a color altogether
* "extract" a color. That is, given a ramp ABCD, remove C from the ramp, resulting in a ramp ABD (with C being either in a new ramp, if it wasn't part of any other ramps, or connected only to the colors in those other ramps). Not very simple UI-wise -- best choice might involve offering a menu of ramps to remove the color from, with a checkbox for each.
* Connect two/three colors (eg. given existing ramp ABD and other ramp including C, insert C next to B). Probably needs to be some kind of drag operation. There is the question of insertion order (if you drag C -> B, does that mean you want C between B and D or between A and B?). It might work best to use a mostly automatic ordering (if you drop on the centre of B,  the brightnesses (LAB L value) of A B C D should be compared to determine insertion location; if you drop near the B D border, it is inserted  after B; if you drop near the A B border, it is inserted before B. Behaviour at ramp ends would be variants of these cases.
 In the case where any of the colors involved are already 4-connected, the operation is automatically canceled with an appropriate error report.

* Move a color within a ramp. The simplest approach may be to consider this as a case of 'connect two/three colors' where the color in question is already within the ramp, and is just disconnected from its old location before performing the connection.

The chief disadvantage of this approach, AFAICS, is instability. When you add a new color to the palette, or change connections, the palette needs to be automatically repacked, and it may not be possible to guarantee preservation of most of the old layout. That said, this isn't  much worse than a typical Photoshop or GIMP palette setup, where inserting colors shoves the following colors forward.