Examples

Internally, the hiding is done via CSS on the client-side, and CSS syntax and selectors are used to identify the elements to remove.

You often want to hide the form elements "wrapper" div, so the containing element of items starting with #edit- will also be hidden.
Eg, if you are trying to hide '#edit-menu-description', then the whole .form-item-menu-description will be hidden. Inspect the source of any form on your site to see the new classes that have been added to the form element to assist this utility. 

node-form:[#revision-information, #edit-date]

will demote the revision log box and date editor from the interface. 

node-form:[#edit-log, #edit-date, #input-format, #authoring-information, #publishing-options]

is quite aggressive, but makes your interface really clean by removing most admin UI elements.

If you want, you can also enter arbitrary css-selectors. Hiding : 

node-form:[.description,label]
... will make your form really hard to use by removing the labels. Hiding : 
node-form:fieldset.collapsed

will doubly-hide unused (normally collapsed) things.

Syntax

The [] array syntax is optional if only setting one value. 

node-form:#revision-information
node-form:#url
and 
node-form:[#revision-information, #url]
are equivalent, both will work.

Per-content-type rules

Normally the first token in your configs should match the specific form id. 

<form ... id="block-admin-configure" >
Node forms are treated as a special case. You can target specific content types with their explicit form id, eg: 
<form ... id="article-node-form" >
A generic form rule for all node forms can also be defined using the pseudo-key node-form, This will be applied to edit forms for all types. 
node-form:#revision-information
page-node-form:#edit-date
article-node-form:[#menu, #url]
article-node-form:{.user-role-editor:[#book-outline]}
This will: True JSON would want all those values quoted, don\'t do that, the quotes will be added automatically for you
[*] The Book module permissions allow admins to add any content type to books, which is nice, but you can\'t turn that feature off if it\'s unwanted. There are a few user permissions like that throughout Drupal, because admins or UID-1 bypass most of the access checks. This presents us with too many widgets onscreen a lot of the time. Rather than hack the core permissions system, we just remove these options from normal use.

New Nodes

An additional class (.node-new) is added to "new" nodes being created. This allows us to hide even more fields if they are decided to be irrelevant when first making a node, and really clean up the first edit page. 

node-form:{.node-new:[#revision-information,#flag-for-archiving]}

This will make the named form elements unavailable on brand-new nodes.

Per-role rules

node-form:{.user-role-authenticated-user[#comment-settings]}
node-form:{.user-role-content-editor[#file-attachments]}
This will:

The rules define the things to be excluded and they match cumulatively (an OR rule) so take care with per-role settings. Using a rule for .user-role-authenticated-user will also apply to admins and UID-1, as they are authenticated. Using a rule for .user-role-content-editor will apply to admins if that user is also a content editor

Per-role rules are available to all forms, not just node forms. The class to use is always the string user-role- followed by a css-safe version of the role name.

Per-taxonomy rules

Any selectbox on the form will also insert an additional selector into the form element you can use. The format is selected-tag 

node-form:{.selected-marketing[#file-attachments]}
This will: This method may add some weird values in some cases, as every select element is scanned for this feature, not just taxonomies.

Combining selectors

The rules are created using CSS syntax, keyed by the classes that are added to the node form. You can inspect the DOM on the edit page to see which classes have been added for you. Combine the selectors with a "." and no space to create specific restrictions.

page-node-form:{.user-role-content-editor.selected-marketing>:[#comment-settings]}

This will:

With this sort of rule in place, you can allow content editors to control things on other node types (like story or blog) but remove that option from static "page" types. This works around the limitation of Drupal permissions that only enable or disable this feature on a global level.

This is not a substitute for real permissions as the user can choose to expose and use that feature if they really want to. It just removes the clutter from the form for everyday use.

Other forms

Are your users scared of complexity, but you still need to give them access to some Drupal internals? 

block-admin-configure:{.user-role-content-editor:[#edit-user,#edit-role]}

This will remove some advanced elements from the block edit form, but still leave it usable for everyday administration. *

Vertical tabs

* This is not currently compatible with vertical tabs. You can hide elements inside vertical tab groups, but not the whole tab.

Developer

If you want to inspect the CSS rules that are created by this utility, you can check out the URL /advancedform_css/node-form , where "node-form" is any form id. You will see that and "advancedform-filtered" instance of that form will have the named form elements hidden, and if the form is switched (to no longer have the "advancedform-filtered" class), then the hidden elements will show up again.
This utility works client-side with javascript, and has no effect with javascript off (all fields dispaly as normal)