That is expected behavior. If the plugin responsible for a given tag isn't enabled, then no code will parse for that tag and it can't be replaced. So it will stay in the article as it is.
It's the same behavior with the "Load Module" plugin.

Unless someone is going to turn this into a feature request for a post processing step that ensures all placeholder/shortcode type stuff is removed then this can be closed as noted above.

closing then as behaviour, in current code implementation, can't deal with it.
a suggestion though: maybe that content plugin could be enabled by default.
whatcdonyou think?

maybe that content plugin could be enabled by default.

It could, yes. I left it disabled because I think most sites will not need it and it has a minor performance implication since it's going to run on each article (like each content plugin). But if people think it should be enabled by default, then I'm not going to argue ?

enabled by default: +1

also, i think the button field should only display in editor bar if this content plugin IS enabled.

also, i think the button field should only display in editor bar if this content plugin IS enabled.

Just keep it consistent with the "Load Module" plugins.

also, i think the button field should only display in editor bar if this content plugin IS enabled.

I wouldn't. That couples the button to a specific implementation of the plugin. Nothing stops anyone from forking the core content plugins supporting those shortcode syntax things and adapting them to do something different.

See #13946 (had not read @mbabker comment yet)

Nothing stops anyone from forking the core content plugins supporting those shortcode syntax things and adapting them to do something different.

In that case they should imho also fork the existing xtd-button.
Displaying the module and fields button when the only things they will show when rendered would be {whatever} is worse