@Rouben Rostamian  In which version, platform, and input environment are you getting that?

You can put your followup examples here, if someone's Answer's code here doesn't handle the additional cases which you forgot or couldn't be bothered to mention here in the first place.

But don't submit further followup examples in separate Question threads. (You've been told this several times before.)

This is a very good question.

Unfortunately, I don't know a way to completely prevent the AXEXLABELS substructure from being present (without forcibly removing it, as you already showed).

You are right that it is a waste of space, around the plots. And a smaller plot (eg. 200x200 or so pixels for the plot widow...) clearly reveal the wasted space.

As the author of several applications which utilize animated plots within PlotComponents I will say that this is the kind of sloppy GUI handling of plots that really gets in the way of producing better quality results. Jitter in the axes frame, loss of valuable space, lack of symmetry in the visible rendering, and trouble with aligning axes of stacked plots, are just some of the difficulties that application authors encounter that really ought all to be avoidable.

Here is another worksheet that demonstrates the problem. (Uncomment the plots:-display calls for yet another view of the wasted space.) This demonstrates, unfortunately, that Kitonum's suggestion to simply omit the labels option is wholly inadequate and does not fix the underlying issue.

wasted_label_space.mw

I am going to submit a bug report, not so much gainst the GUI's plot drivers for rendering the wasted space as against the Library-side plot constructors for including AXESLABELS("","")  when not requested. (Sometimes the latter kind of silliness gets introduced as a band-aid for irritations with GUI "plot persistence". But I get fed up with dealing with the ensuing difficulties of patches for patches...)

@shankrel You're very welcome.

There are many ways to use Maple to solve this problem.

Since you may be relatively new to Maple, here is one (of several possible) alternatives.

Worksheet_2_ac.mw

@mmcdara Sorry, I didn't read carefully enough, and thought you wanted only the standalone piecewise calls, instead of wanting the sum with only some terms retained. (I think I was confused by the use of the terms "extract" and "operators", which I over hastily took to mean extracting piecewise calls instead of restricting the addends of the sum.)

An adjustment to what I gave earlier is simple.

select(hastype,expr,And(specfunc(piecewise),
                        satisfies(pw->not depends(pw,[x]))));

That produces the result for the given example, and I believe it reads reasonably naturally.

In another, extended example it also excludes any term with a piecewise conditional such as t<0 or x[1]<0 .

You could also use depends(pw,x) in the above, but I thought the list-brackets in depends(pw,[x]) give a little visual hint that additional dependent names can be check together.

If you will eventually need to handle more involved conditionals then this is the time to mention them.

For example (making it up...),     

x(t)<0 and t<0

or,

x(t)<0 and t^2>0

@nitins You're welcome.

As a future consideration you might consider either:
1) Uploading and attaching the actual worksheet (as Georgios requested, using the Mapleprimes editor's green up-arrow),
or,
2) Telling us where you obtained the worksheet, so we don't have to Google it. Worksheets come from many different places. (This site's editor allows for URL links to be inserted in postings.)

@Carl Love The given code does subs(i1=id, eq1) where eq1 is not yet assigned anything. So some formula for eq1 is indeed needed prior to that. It is also true that an original definition of id is missing.

All three original definitions of eq1, eq2, and id are needed, yet missing.

@nitins Where is the original definition of the circuit equation? It should be assigned to eq1, prior to the pertinent subs call.

And where is eq2 defined?

Also, the calls to odeplot(...) won't do anything since the plots package is not being loaded. You could change those to plots:-odeplot(...) , after other corrections.

@Ramakrishnan Your claim is not correct. That font specification affects the sin but not the numeral 30. Try with Courier or Arial, and you can see that the numeral is unaffected.

That is why he followed up, to mention that fact.

And that is why I have now followed up with some alternatives, which do affect the numeral.

@mapleatha Sorry, I was focused on removing the italics, and forgot about your font specification.

You could choose from these, where I would guess that the first might be easiest (while still being programmatically flexible):

plots:-textplot({[4.2,1.9,sin(Typesetting:-mn(cat(30,"°")))]},
                symbol=point,color=black,
                font=["Arial","Bold",25]);

plots:-textplot({[4.2,1.9,Typesetting:-mn("sin(30°)",
                                          mathsize="25",
                                          fontfamily="Arial")]},
                symbol=point,color=black);

plots:-textplot({[4.2,1.9,Typesetting:-mn("sin(30°)",
                                          mathsize="25",bold="true",
                                          fontfamily="Arial")]},
                symbol=point,color=black);

@mmcdara Such automatic pretty-printing of the Logic operators (in output) was introduced in Maple 2017.

It is possible to define printing procedures for &and, etc, for earlier versions such as Maple 2015. But note that such would require extra delimiter round-bracketing, to avoid problems with precedence. And the brackets look ugly when not necessary -- but discerning when necessary could get technically difficult within such a mechanism.

Here is a crude start on such pretty-printing in Maple 2015. As is, it will not get the bracketing correct. naive_log_pr.mw I actually think it's a waste of time to work on this for Maple 2015 as the Copy&Paste or such pretty-printing output doesn't properly work with this in even Maple 2015.2.

Even with interface(typesetting=extended) forced in one's Maple 2015.2 I don't think that the Typesetting:-RuleAssistant can be used successfully and conveniently to get those pretty-printing effects.

Overall, I'd say you're better off relying on your later Maple version, for such pretty-printing effects.

The ability to utilize names beginning with & as infix neutral operators is documented on the neutral Help page.

I have submitted a bug report (ie. SCR, software change request).

@C_R Quite a lot of your last response indicates that you consider ()() as a distinct piece of syntax. But it isn't, really. It is use together of two separate bits of syntax: one pair of parentheses for grouping or delimiting terms that will be applied (like an operator), and a second pair of parentheses that denotes function application (and groups the arguments of that, if any).

Yes, parentheses thus serve two different syntactic purposes here.  Both these purposes of parentheses (grouping or delimiting of terms, or denoting function application) can also be used separately. Yes, you can utilize both together, but it's not a single piece of syntax.

The case of grouping or delimiting expressions (that are to be used as an operator) isn't just useful for composition and arithmetic of the terms. Another important class of example is using parentheses to delimit an expression or an anonymous procedure.

There are currently at least seven examples of using the grouping/delimiting parentheses together with parentheses for function application, on the examples/functionaloperators Help page.

I like your example using parentheses to delimit an equation used in function application. An example such as (f=g)(x) would be useful on that Help page.

ps. I think that whattype isn't highly useful and shouldn't be emphasized as if it were.

pps. Round-bracket parentheses can also denote indexing of rtables.

@rlopez Here are some examples (using row Vectors to render results side-by-side without separating commas). You should be able to see which names in which subscripts are in italic versus upright roman. 

Download subscriptroman.mw

That makesub2 is a little "stronger" than that makesub, as it can handle pretty-printing of some additional compound expressions.

ps. I see only mention of indexed names in the current version of the Question. Did the OP actually ever ask about "subscripted" names? Otherwise, I don't understand why Carl wrote at length here about so-called atomic, subscripted names versus indexed names.