Turns out my earlier reply was the right answer to the wrong question. Turns out it is more subtle…
This is an interesting interconnection of issues and gives me flashbacks to a previous career as a data emergency plumber (“I just need to to move from [system] to [system], how hard can it be? <eye roll/sigh>”). To be clear, there is no deliberate error here, only assumptions that in hindsight proved sun-optimal (for app and user0.
Before going into the weeds of the problem, I think it worthwhile stating the Tinderbox calls itself a ‘toolbox for notes’ and whilst it has automation in Action code, that Action code is not a programming language. It may look like one, and essentially act like one, but it is dangerous to work as it it is one. Why does that matter? Because Action code has accreted features over time, which have left some hard-to-backfill oddities, and UI-based (can’t see it → it doesn’t exist) users and automation users can pull the poor developer in conflicting directions with their feature requests. A case in point is summed up here: Problematic Characters for Action code in $Name and $Path. It isn’t the problem here but the latter neatly illustrates the nature of preceding point, and gives a hint of what is to follow…
With attribute values, if Tinderbox knows no better it gets treated as a string (of characters). Strings are stored as (straight) single/double quote enclosed values. Thus, either of these:
$MyString = "some value":
$MyString = 'some value';
If typing a value directly into an input box (Quickstamp, Get Info, Displayed Attributes table, etc.) the outer quotes are assumed and to don’t type them. I’m using code to avoid a slaw of screen grabs being needed.
As long as matched in type their can be used, leading us to the ability for one type to enclose the other:
$MyString = "It was Peter's fault.";
$MyString = 'A loud "Huzzah!" was heard';
As long as the outer pair of quotes are the same type and not used in-value, further variations of in-string quote use are are available. Note (as we’ll come back this) that the default/assumed form of delimited quote is straight double quotes.
But what about the parentheses? Stay with me, a bit more scaffolding explantation first…
A list in Tinderbox (used by List, Set and Dictionary data types) is essentially a string where the semicolon act as as the delimiter:
$MyList = "winken;blinken;nod";
But, you say, need a list item called ‘winken;blinken’. We can do that:
$MyList = 'winken';'blinken;nod';
//or
$MyList = '"winken;blinken;nod';
… gives a 2-item list. Note the outer quotes (the set you don’t type if typing not a Displayed Attributes table value box) are single quotes. So can a list have parentheses (BrE: brackets) in a value? Yes:
$MyList = "winken(blinken);nod";
gives 2 items: winken(blinken) and nod.
So why does your code fail? It turns out that whilst a simple list-based attribute can happily hold parentheses, the collect(), .format() and an unknown number of other list-operators cannot safely handle parentheses in item values. So, they first sanitise the string by enclosing ‘bad’ items in double-straight-quotes for onward processing. But, unhelpfully, the process doesn’t then remove them when done and thus—finally!—we find out why you have the stray quotes.
What to do then? It turns out it is quite simple, now we know how/why the unwanted quotes are arising. This works:
$Subtitle=;
collect(children,$Text).each(anItem){
$Subtitle+=anItem+'\n' ;
};
$Subtitle=$Subtitle.replace('"',"");
N.B. the first argument in the .replace() call needs to use single quotes as they have to enclose a double-quote character (and Tinderbox has no escape mechanism for straight single/double quote characters).
Now that is out of the way, you really don’t need the .each() here, as there is a simpler approach. What you want to do is get all the child values and make them into a one-source-value-per-line price of text. IOW, you want to join all the list items into one string using a line space character as the join. You do that using .format():
$Subtitle=collect(children,$Text).format("\n").replace('"',"");
There’s no single ‘right` way! for the doubting, here is the last above, applied in @jbmanos’ test doc:
See, no stray quotes. though removing them was easy, knowing why they occurred and thus where in the process to remove them proved more complex.
To avoid those awful imported attribute names , see here and here. If you can’t edit the source process (e.g. someone else made the data it’s a closed system), I would, having first read the two preceding pages, edit the CSV file in something like BBEdit from:
Thing or Event,Full Text,"Radio Button for Thing, Event (label)",Year,Month (label),Day,Details
to
Name,FullText,ThingType,Year,MonthNumber,Day,Details
As we know the month is a number (e.g. 2 now February) we’d pre-make a number-type user attribute MonthNumber as auto generated attributes generally default to a String type. In this case you could just the data-type of ~MonthNumber` after import as a string won’t alter numbers passed to it; but, learning on my old data-plumbing days, don’t make the software guess when you can easily provide the correct answer and save yourself work.
Sorry for the answer but the simple solution tat the end would have made little sense without some explanation and exploration (where did my morning disappear to?).
HTH 
(I’ll check with the developer before editing aTbref as I know this parentheses-leading-to-quotes issue is new (it’s more an awkwardly handled edge case than a simple bug) and I’m not sure if there is/will be a fix.)
